Od kilku miesięcy przez mediach społecznościowych przetacza się fala dyskusji o tym, czy Agile umarł. Temat nie jest nowy, co więcej – jest to odgrzewany kotlet z 2014r. kiedy to jeden z sygnatariuszy słynnego Agile Manifesto, Dave Thomas, opublikował krótki post pod wymownym tytułem “Agile is Dead (Long Live Agility)”.
O co w ogóle w tej dyskusji chodzi? I jak się to ma do innych branż?
Aby zrozumieć kontekst, cofnijmy się do zamierzchłych czasów raczkującego IT. Dominowały wtedy tradycyjne metody wytwarzania produktów i usług IT, czyli: zbieramy wymagania od klienta – projektujemy system – tworzymy go – testujemy – dostarczamy do zadowolonego klienta 🙂
Ten model dość dobrze działał, gdy zespół ekspertów tworzył oprogramowanie dla biznesu, na którym świetnie się znał – np. przez lata dostarczał software dla branży powiedzmy medycznej, znał więc terminologie, procesy, ogólne wymagania, itp. Taki zespół sprawdzonych w boju programistów najczęściej bardzo dobrze rozumiał, co jest przedmiotem zamówienia, a jeśli była konieczność doprecyzowania czegoś, umawiali się z klientem i omawiali szczegóły. Rozumieli siebie wzajemnie.
Z czasem zapotrzebowanie na programistów zaczęło rosnąć, brakowało doświadczonych rąk do pracy jak i czasu na wzajemne zrozumienie stron. Bardzo wrosła też złożoność zamawianych systemów – nie były to już proste programy obliczeniowe. W efekcie, świat IT i biznesu zaczął się rozjeżdżać – tak dalece, że zaufanie erodowało, a współpraca przypominała mękę.
Ludzie z IT mówili o ‘niezdecydowanych klientach’, którzy ‘przysyłają kiepskie wymagania’, zarządy negocjowały coraz bardziej wyrafinowane umowy, aby zabezpieczyć się na wszelkie możliwe sposoby, rosły góry dokumentacji, a proces wytwarzania oprogramowania bardzo się wydłużył i zbiurokratyzował. Każda ze stron okopała się na swoich stanowiskach.
W raczkującym wtedy Internecie pojawiły się pierwsze memy – m.in. ten, odnoszący się do przepaści dzielącej świat firm dostarczających i zamawiających oprogramowanie:
SCRUM
W połowie lat ‘90 podjęto ciekawą próbę naprawy tej sytuacji i zaproponowano proces iteracyjnego, przyrostowego budowania produktu/usługi o nazwie SCRUM. Dzięki temu, klient mógłby znacznie wcześniej zobaczyć, co jest robione i mieć wpływ na prace już w toku, a nie tylko płakać nad odebranym systemem do niczego, na który wydano fortunę.
Scrum było jedną z wielu odpowiedzi na opisane wcześniej bolączki, ale jak historia pokazała, przez kolejne ponad dwie dekady stało się opcją, która zdominowała rynek.
Idea Scrum jest całkiem fajna – w skrócie, sprowadza się do:
- skupienia się zespołu na wytwarzaniu wartości biznesowej wspólnie z użytkownikami, z klientami, ogólnie: “z biznesem”
- otwartości nawet na częste zmiany priorytetów i wymagań ze strony klienta
- dużej elastyczności, transparentności
- wzajemnego wspierania się i angażowania w projekt wszystkich zainteresowanych stron
- nad całością czuwa “scrum master”, wspierający zespół i organizację w doskonaleniu zwinności
- wbudowania mechanizmu uczenia się i zmiany → retrospektywa, czyli omawianie przez zespół tego, co działa dobrze a co nie działa, prowadziła do nieustannego usprawniania procesu wytwarzania; cudo!
Silną stroną była też osoba product ownera, który miał decydujący głos na temat rozwoju produktu, budżetu, itp, co było szczególnie ważne przy rozwoju produktu dla wielu klientów (bądź rynek masowy) – taki właściciel produktu był bardzo mocno osadzonym decydentem, z pełną odpowiedzialnością za biznesową wartość tego, co zespół wytwarza.
Scrum szerszej publiczności przybliżyła publikacja: “SCRUM Software Development Process” by Ken Schwaber (1995, 1996)
AGILE
Do końca lat ’90 Scrum jednak (jeszcze) światowej kariery nie zrobił, a problemy z szybkim dostarczaniem przez IT wartości biznesowej pogłębiały się. Kilka lat później, w 2001 roku, 17 łebskich gości zaangażowanych w usprawnianie procesów wytwarzania oprogramowania, zebrało się w Utah, nie tylko aby pojeździć na nartach. Chcieli coś zmienić. I to im się udało. Dość szybko zrozumieli, gdzie leżą problemy i jak można uzdrowić chorego pacjenta. Tak powstał słynny “Agile Manifesto” (link) czyli manifest dotyczący zwinnego wytwarzania oprogramowania. Warto przytoczyć jego esencję:
Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:
- ludzie i interakcje ponad procesy i narzędzia
- działające oprogramowanie ponad szczegółową dokumentację
- współpracę z klientem ponad negocjacje umów
- reagowanie na zmiany ponad realizację założonego planu
Zanim te wartości trafiły pod strzechy, pierwsza połowa lat 2000 wciąż zdominowana była przez projekty IT, które trwały za długo, kosztowały za dużo i nie dowoziły tego, co trzeba. Powodowały też ogrom frustracji po stronie programistów zmagających się z nie tylko z coraz to nowszymi technologiami (których zazwyczaj bardzo chętnie się uczyli), ale też z coraz trudniejszymi i zmiennymi wymaganiami biznesowymi (których najczęściej szczerze nie cierpieli).
Czas chwały i… spieniężania sukcesu.
Aby spopularyzować nowe podejście, część sygnatariuszy postanowiło kontynuować pracę i założyło Scrum Alliance – organizację non-profit promującą Scrum, która zapewniała zasoby i wsparcie dla osób i organizacji chcących stosować tę metodę pracy. W 2009 wspomniany wcześniej Ken Schwaber – przez jednych określany jako geniusz, przez innych jako lepszy cwaniak – odłączył się od tej grupy, aby założyć firmę scrum.org i na “zwinnej rewolucji” dobrze zarobić. Firma ta certyfikowała w “byciu zwinnym”, a mianowicie, w umiejętności stosowania SCRUM. Od lat wydaje ona certyfikaty, szkolenia, ma świetny marketing i na wiele lat zdominowała rynek. Dość powiedzieć, że Scrum i Agile w umysłach wielu stały się wręcz synonimami.
Marsz sukcesu stał się jednocześnie początkiem upadku: agile stało się “buzzword”, ludzie certyfikowali się na potęgę, rola Scrum Master otwierała drogę do kariery w IT i dużych pieniędzy. Na tej fali powstało wiele szkół, szkółek i “ekspertów” zapewniających, że można zostać Scrum Masterem w weekend i wejść do mlekiem i miodem płynącego świata IT.
Czas erozji i upadku.
Gwałtowny wzrost popularności Scrum miał swoje konsekwencje w jakości. Nie było wystarczającej liczby profesjonalistów, wydawane co jakiś czas oficjalne przewodniki “Scrum Giude” stały się niczym biblia, słowa traktowano literalnie, a ceremonie Scrumowe zatraciły swój głębszy sens, stały się zdarzeniami, które trzeba odbębnić. Firmy zaczęły “wdrażać agile”, często odgórnie, bez odpowiedniego przygotowania i bez zmiany kultury organizacji. Choć w znacznej części świat IT z chęcią i otwartością przyjmował te zmiany – zespoły dostały więcej swobody i możliwości kontaktowania się z użytkownikiem końcowym – brakowało jednak osób zarówno z odpowiednio dużym doświadczeniem w „zwinnej pracy”, jak i umiejętnościami skutecznego przeprowadzenia zmian w organizacji. Często brakowało też wsparcia “góry”: zarząd chętnie chwalił się, że firma “jest agile”, ale problemem było przekazanie decyzyjności i odpowiedzialności w dół organizacji.
Na zmiany w IT z boku patrzyli klienci (biznes): dla większości z nich była to mało zrozumiała fanaberia, moda, która przeminie. Nie było więc chęci (brak czasu) włączenia się w prace IT pełną parą. Nie było chęci oddania “władzy” nad produktem biznesowym product ownerowi (więc IT tworzyło własnych, znacznie słabiej zorientowanych biznesowo i niedecyzyjnych). Nie było chęci rozmawiania z IT na co dzień – “niech pokażą co zrobili i wtedy ocenimy”, “nie mamy czasu”, “odpowiem za tydzień/miesiąc”… To nie tak miało wyglądać.
Okazało się, że zdobycie certyfikatów i “wdrożenie scruma” jednak nie czyni firmy zwinnej, jak za dotknięciem magicznej pałeczki. Tę sytuację napiętnował Dave Thomas w 2014r publikując wspomniany na początku artykuł i wieszcząc śmierć Agile.
Umarł król, niech żyje król!
Ani w 2014r. ani w latach późniejszych Agile tak całkiem nie umarł. Co więcej, mnóstwo firm wciąż chciało “być agile” i “wdrażać agile”. Jednak pojawiło się wiele nowych, konkurencyjnych dla Scrum frameworków – np. świetnym marketingiem SAFe (Scaled Agile Framework, link) szturmem zdobył serca korporacji, które chciały ‘być zwinne’, nie bacząc na to, że część środowiska protestowała przeciwko “A” w akronimie zarzucając, że ciężki, skomplikowany i nastawiony na pracę top-down SAFe ma niewiele wspólnego z Agile. Spopularyzowała się koncepcja DevOps (w wielu odmianach). Ratować skórę Scrum/Agile próbował też stary, poczciwy Kanban (używany w Japonii już w latach ‘50 XXw), a popularność zdobył termin ScrumBan łączący oba podejścia.
Co dalej? Trudno powiedzieć, w którą stronę pójdzie rozwój wytwarzania oprogramowania. Z pewnością Scrum dalej będzie obecny w wielu firmach, tak jak liczne warianty i odmiany innych metodyk Agile’owych. Samo podejście Agile rozprzestrzenia się coraz śmielej i z powodzeniem poza IT. Coraz więcej mówi się o “customer experience”, “user experience”, o tym, że nie sprzedaje się towarów/usług, tylko doświadczenia, emocje. A firmy, które to zauważyły i wykorzystują, już zdobywają przewagę konkurencyjną.
Z tej perspektywy dyskusja o tym, czy agile żyje czy już dogorywa, jest drugorzędna. Pisał o tym m.in. Jurgen Appelo (link) – założyciel podbijającego serca (i rynek) ruchu Management 3.0 – któremu zależy na tym, „aby ludzie cieszyli się pracą, a użytkownicy mieli świetne doświadczenia z produktami i usługami.”
Jakkolwiek sytuacja się nie rozwinie, pewien jestem, że – nawet jeśli agile is dead – to z pewnością żyje i ma się świetnie agility, czyli zwinność. Zwinność umysłu, zwinność w podejściu do pracy, zwinność w wykorzystywaniu dostępnych narzędzi. Agile umarł? Niech żyje zwinność!
O autorze
Dawid Wacławski – specjalizuje się w tworzeniu i prowadzeniu szkoleń, warsztatów, wykładów oraz długofalowych programów rozwojowych z zakresu kompetencji przywódczych i menedżerskich, współpracy międzykulturowej oraz efektywnego działania zdalnych (rozproszonych, wirtualnych) zespołów. Bazuje na ponad 20-letnim doświadczeniu zawodowym w IT, w tym 15 lat w roli lidera i menedżera, głównie w środowisku międzynarodowym. Dawida znajdziesz na LinkedIn oraz www.
Dawid był też gościem podcastu O Krok Do Przodu. Posłuchaj rozmowy: Świetny menadżer w IT – 10 kluczowych cech
Photo by Eden Constantino on Unsplash
Skomentuj artykuł