Agile is dead. Czy to prawda? I jaki agile? O tym w dzisiejszym odcinku, w którym rozmawiam z Dawidem Wacławskim. Porozmawiamy o tym, o co w ogóle chodzi w tym Agile is Dead, jak patrzeć na to zjawisko i jak je rozumieć. Omówimy temat tak, żeby także osoby, które na co dzień nie są ekspertami Agila, rozumiały o co w tym wszystkim chodzi.
Czego dowiesz się z tego odcinka:
- Czy agile is dead?
- Agile jako formuła pracy vs. Agile jako mindset
- Skąd się wziął Agile?
- Po co nam Agile?
- Na czym polega Agile SCRUM i co w nim jest super?
- Dlaczego pojawiają się hasła, że Agile is dead?
- Co jest przed nami?
Gdy będziesz słuchać tego odcinka, pomyśl o osobie, która też wysłuchałaby go z korzyścią dla siebie lub swojego zespołu i podziel się linkiem do nagrania.
Podsumowanie odcinka:
Kiedyś standardy i trendy w zarządzaniu wyznaczały realia fabryki. Wygląda na to, że teraz standardy i trendy w zarządzaniu pochodzą nadal z procesu produkcji, tym razem produkcji oprogramowania. To, o czym dzisiaj rozmawiamy: Agile, zestaw metodyk i machina certyfikująca, to nie to samo co Agility, czyli zwinność w działaniu. A jeśli tak, to być może Agile is Dead, ale Long Live Agility, niech nam żyje zwinność w działaniu. Najważniejsze jest doświadczenie klienta, to też jeszcze jedno kluczowe hasło, które zabieram sobie z tego odcinka.
Podziel się swoimi przemyśleniami – tutaj na portalu, lub na naszym profilu na LinkedIn.
Zapraszam Cię do zapisania się na newsletter i obserwowania profilu na LinkedIn. Subskrybuj też kanał O Krok Do Przodu na wybranej platformie i dziel się ze znajomymi.
Materiały i źródła wymienione w odcinku
- Wartości Agile Manifesto (2001)
- Video Agile is Dead by Dave Thomas (2014)
- Wystąpienie Kena Schwaber na temat (kiepskiej już wtedy) kondycji agile (2014)
- Video Jurgen Appelo (2023)
- Stacey Complexity Model – kiedy (nie) stosować agile
- Podcast OKDP 023: Cztery pokoje zmiany. Jak pomóc Twoim ludziom przejść zmianę szybciej i efektywniej
- Podcast OKDP 066: Wstyd Technologiczny Pokolenia Z
- Podcast ASA 005: Part Time Manager. The Future of Work.
Dyskusja o Agile
Kiedy myślimy o tym, co się działo za oceanem i jak powstał Agile, możemy też pomyśleć o Jurgenie Appello, który odnosi się do tej dyskusji, że Agile is dead. W jego słowach „Agile is dissolving”, czyli tak jakby rozpływa się, rozwadnia się, rozpuszcza się. Ja jestem tym trochę zaskoczona i patrzę na tą dyskusję jako na takie ścieranie się dogmatów.
Jurgen Apello w swoim artykule z 2023 napisał „I don’t care if Agile is dead or Agile has won.” I tu się odnosi do sztucznej inteligencji, do AI. Na górze jego artykułu jest szef chińskiej firmy Hire – to jest największy na świecie producent AGD. I tam jest taki tekst, który mówi:
„Traditional brands focus on the upgrading of products, but we focus on the iteration or upgrading of user experiences.”
Tu jest chyba klucz do zrozumienia tej zmiany, która następuje. Agile jako taki skupiony jest na produkcie. Tam mamy product ownera, mamy product backlog, mamy wiele innych terminów związanych z produktem i wokół tego krąży cały temat. Natomiast świat poszedł do przodu i to, co się liczy to są właśnie user experience, customer experience, emocje. Sprzedajemy takie rzeczy. Nie sprzedaję tylko lodówki, ale cały user experience z używania tej lodówki.
On też później powiedział, że zależy mu tylko na tym, żeby ludzie w miejscach, w których pracują mieli z tej pracy radość, żeby byli zaangażowani. A użytkownicy produktów czy usług, które wytwarzają, mieli świetne doświadczenia z tym produktem i z tymi usługami. To się liczy, a nie tylko to czy jesteśmy agile czy nie. Niestety po latach właśnie do tego się często rozmowa sprowadzała.
Agile jako formuła pracy, a Agile jako mindset
Może zacznijmy od początku i rozróżnijmy skąd się wzięło to słowo Agile. Myślę, że warto wrócić do 2001 roku, w którym powstał tzw. Agile manifesto, czyli manifest zwinności. Warto tutaj przytoczyć na czym on polegał.
Mówi on o tym, że ludzie i interakcje są ważniejsze niż procesy i narzędzia. Działające oprogramowanie jest ważniejsze niż szczegółowa dokumentacja. Współpraca z klientem jest ponad negocjacją umów, a reagowanie na zmiany jest ponad realizację założonego planu.
To jest taki duch zwinności, który tworzył podwaliny pod dalszą rewolucję.
Tu chciałbym rozróżnić pojęcia Agile i Agility. Termin Agile is Dead pojawił się już 10 lat temu, w 2014. Tego terminu użył jeden z sygnatariuszy manifestu Agile, Dave Thomas. On napisał artykuł Agile is Dead – Long Live Agility. To jest ta różnica. Agile stał się po latach wdrażania jakimś takim buzzword, takim słowem kluczem, wytrychem. Za dużo w kołu tego marketingu, za dużo certyfikatów, szkoleń, szumu itd. A za mało było rzeczywiście tego ducha, który był w manifeście ogłoszony.
Potrzebne jest to rozróżnienie między Agilem jako pewnym systemem pracy, a Agility jako sposobem podchodzenia do rozwiązywania problemów, taka zwinność umysłowa.
Co to jest Agile
Agile to jest przede wszystkim mindset, czyli nastawienie, stan gotowości i otwartości do pracy nad organizacją. Ale też nad sobą, nad spotkaniami, nad tym jak pracujemy, w jaki sposób wytwarzamy oprogramowanie, produkty czy usługi. Stan gotowości do zmian i chęci do tych zmian. To jest zwinność, a właściwie jedna ze zwinnych cech.
Natomiast jeśli chodzi o frameworki, metodologie, sposoby pracy, to najpopularniejszym jest Scrum. Później z czasem też Kanban przyszedł na pomoc Agilowi, ale chyba go nie uratował.
Czym jest SCRUM
Scrum jest starszy od manifestu agile’owego. Scrum powstał w 1995 roku jako metodologia pracy, proces iteracyjny. To był proces iteracyjny przyrostowego budowania produktu i usługi.
Cofnijmy się jeszcze bardziej w historii, skąd się to w ogóle wzięło. Wcześniej produkowano oprogramowanie w ten sposób, że umawiano się na coś z tak zwanym biznesem czy z klientem, klient mówił czego potrzebuje, IT przyjmowało takie zlecenie, budowało i dostarczało produkt lub usługę. Zamawiam, dostaję, odbieram.
Problem pojawił się wtedy, kiedy ludzie z IT przestali rozumieć biznes. Czyli zaczęła się tworzyć duża liczba programistów, którzy niekoniecznie znali domenę biznesową, w której działają i nie rozumieli tego, co klient do nich mówi. Nie za bardzo wiedzieli o co chodzi, więc robili tak, jak rozumieli. Stąd są później te śmieszne rysunki, co klient zamówił, a co otrzymał.
Stąd są potem opóźnienia w projektach, bo powiedzmy, że wyceniamy coś na trzy miesiące pracy, a potem dostarczamy po pół roku pracy, no i się okazuje, że budżet przepalony, albo nawet trochę więcej, a otrzymaliśmy kompletnie co innego niż nam jest potrzebne.
Scrum to fajnie ujął w sposób działania. Ma on bardzo dużo zalet.
Jaki jest zespół SCRUMowy
Jedną z takich fajnych zalet jest to, że zespół jest skupiony na wytwarzaniu wspólnie z użytkownikami końcowymi, z biznesem. Czyli w zespole scrumowym powinien być ktoś, kto będzie blisko współpracował z biznesem na co dzień.
Zespół scrumowy jest też otwarty na częste zmiany priorytetów. To nie jest problem, jeżeli w połowie pracy przyjdzie ktoś i powie, że musimy jednak to zmienić. Scrum jest dosyć elastyczny, transparentny.
Scrum wspiera współpracę wszystkich zainteresowanych stron, angażuje.
Super ważna rzecz to jest też wbudowany mechanizm uczenia się i zmiany, czyli retrospektywa. Spotykamy się co jakiś czas, rozmawiamy o tym, jak nam idzie, czy coś zmienić, czy coś ulepszyć. To są bardzo ważne rzeczy.
No i Scrum ma tego nieszczęsnego product ownera, który z założenia miał decydować o rozwoju kierunku, miał być takim domenowym ekspertem, wspomagającym zespół. Miał decydować o budżetach, o wymaganiach, o tym co robimy, czego nie. Więc te założenia rzeczywiście były piękne, natomiast w życiu wyszło niekoniecznie tak fajnie.
Problemy SCRUM
Główne problemy jakie Scrum napotyka na co dzień to to, że najpierw musimy wdrożyć Scruma, czy wdrażamy zwinność. Nie da się do firmy, która od 20 lat działa w jakiś sposób, nałożyć tylko nakładki. „No to teraz spotykamy się co rano, robimy daily, rozmawiamy o naszych problemach i postępach, spotykamy się co dwa tygodnie, żeby porozmawiać o tym, co ulepszyć.”
Jeżeli nie ma w zespole zaufania, to przecież nikt nie powie o problemach i o blokerach, przed którymi zespół stoi.
Tylko to będzie albo jakieś milczenie, albo przemieni się w narzekactwo, z którego nic nie wynika, albo sobie ludzie po prostu pogadają przy piwie, bo to też można organizować poza firmą i nic się z tym nie zadzieje.
Problemy product ownera
Jednym z głównych dużych problemów ze Scrumem jest rola Product Ownera, która z założenia miała być bardzo silna i decydująca. W praktyce w większości firm Product Owner to jest dość słabo umocowany ktoś, kto łączy IT i biznes. Ale tak naprawdę nie ma żadnej decyzyjności, nie ma budżetu. Zawsze musi czekać aż ktoś wyżej zatwierdzi jego decyzję na podstawie jakichś tabelek w Excelu czy dwóch slajdów prezentacji.
Więc taki Product Owner musi czekać na decyzję kogoś. Te decyzje wiszą w powietrzu, paraliżując zespół i to, co miał dostarczać. To jest kompletne odwrócenie tego, co miało być.
Kultura firmy
Mówi się, że Scruma trzeba „wdrożyć całego albo wcale”. Natomiast to nie do końca tak jest, bo pomija się taki aspekt jak kultura firmy. I tutaj jest mnóstwo rzeczy pod spodem jak zaufanie, relacje w firmie, mindset.
Jeżeli zmusimy ludzi do takiej retrospektywy, żeby spotkali się raz na jakiś czas i porozmawiali, ale nie ma tam zaufania, nie ma dobrej komunikacji, to to spotkanie będzie kiepskiej jakości, za dużo się nie zadzieje.
Więc jeżeli mówimy o wdrożeniu Agila, czy wdrożeniu jakiejś zmiany, to musimy zacząć przede wszystkim od postaw, od kultury, od mindsetu.
To jest podstawa. Nie narzucanie jakiegoś frameworka, który gdzieś się sprawdził.
Spotify Model
Świetnym przykładem jest słynny Spotify Model. Firma Spotify wprowadziła zmianę lata temu. Oni dostosowali zwinność, czy wzięli z Agila to co najfajniejsze, zaimplementowali to u siebie w pewien specyficzny sposób, stworzyli własną strukturę dostosowaną do swojej kultury organizacyjnej. I świetnie im to zadziałało. Dostarczali szybko wartość dla swoich klientów.
Świat się tym zachwycił, jak oni potrafią tak szybko wytwarzać oprogramowanie takiej świetnej jakości. Konsultanci z największych firm obsiedli tą firmę i napisali, że jest takie coś jak Spotify Model i oni będą teraz wdrażać ten Spotify Model w innych firmach.
Oczywiście takie kopiuj-wklej niczego dobrego nie przyniosło, bo każda firma ma swoją własną kulturę organizacyjną. Więc próba takiego skopiowania i wklejenia Spotify Model spaliła na panewce.
Scrum Master i Agile Coach
Rola Scrum Mastera ewoluowała. Co jakiś czas wydawane są Scrum Guidy, czyli organizacja scrum.org wydaje takie instrukcje jak być powinno i jaka jest czyja rola, kto za co odpowiada. Natomiast rola Scrum Mastera z czasem ewoluowała też do roli Agile Coach.
Agile Coach to jest osoba, która próbuje zmieniać organizację od środka.
To jest jej główna rola. Nie tylko praca z zespołem, ale też praca na poziomie organizacji, na poziomie managementu. Chociaż to powinien właściwie robić Scrum Master według tych założeń, jakie od początku przyświecały tej roli.
Temat jest trudny, bo rola Scrum Mastera jest bardzo ważna, jest jedną z kluczowych i wymaga ogromnej wiedzy i doświadczenia. Bez tego Scrum Master nie wniesie do organizacji tego, co powinien.
Kiedy (nie) stosować Agile
Z Agile to nie jest tak, że zawsze pasuje do wszystkiego. Znany jest Stacy Complexity Model, który pokazuje, kiedy stosować jaką metodę.
Metoda A
Jeżeli mamy biznes, w którym próbujemy wytworzyć jakiś produkt czy usługę i mamy zespół, który jest doświadczony, który już ze sobą współpracuje od lat i wie o co chodzi, to nie ma problemu, właściwie mogę pracować w czymkolwiek. Najczęściej w takich sytuacjach dalej się stosuje stary, dobry waterfall, czyli po kolei: najpierw zbieramy wymagania, tworzymy projekt, programujemy, testujemy i dajemy klientowi. Wiemy o co chodzi. Ja wiem co mam robić, wiem ile mi to czasu zajmie. Klient wie czego się spodziewać, ja to zrobię dobrze, solidnie na czas.
Metoda B
W świecie, w którym technologia się szybko rozwija, mamy co rusz jakieś nowe frameworki, języki programowania itd. Kiedy wymagania są nie do końca znane, bo nawet osoby zamawiające po stronie biznesu nie do końca wiedzą czego chcą, bo rynek jest tak zmienny, płynny, to mamy wtedy problem. I mamy rozwiązania typu kompleks, czyli technologia jest płynna, ja mam średnie doświadczenie w tych technologiach, wymagania są płynne. Wtedy rzeczywiście metody zwinne sprawdzają się lepiej. Nie jestem w stanie powiedzieć w momencie rozmowy z klientem co dokładnie będzie zrobione, za ile czasu i za jakie pieniądze, bo po prostu tego nie wiemy.
Metoda C
Natomiast jest jeszcze trzecia skala, kiedy zupełnie nie wiem o co chodzi, jest kompletnie nowy temat technologicznie, zupełnie coś nowego, tak jak teraz AI. Jeszcze nie do końca wiemy gdzie i jak tego użyć. Są już próby, natomiast dopiero z tym zaczynamy. Z drugiej strony biznes też jeszcze szuka w jaki sposób tego użyć. Tutaj mamy bardzo dużo technologicznych niepewności i bardzo dużą niepewność biznesową. I to jest obszar, który nazywa się czasem anarchia, czasami chaos. Tutaj żadna z tych metod nie zadziała dobrze. Próbuje się podejścia typu lean startup, albo innych. Bardzo szybko coś wytwarzam i testuję na rynku jak to działa, a potem zmieniam.
Natomiast agility jako mindset pasuje tutaj idealnie. Więc long live agility jak najbardziej.
Niech nam żyje zwinność w działaniu!
Is Agile Dead?
Ja myślę, że rzeczywiście Agile jako taki klucz, buzzword, taki wytrych do wszystkiego, taka próba wciskania czegoś jedni drugim na siłę, to absolutnie takie coś już odchodzi do lamusa. Natomiast Agility jako takie, czyli zwinność, czy sposób sprytnego podejścia do pewnych problemów to jest nieunikniona rzecz. To jest jedna z przewag kompetencyjnych, którą firmy powinny mieć.
A co dalej? Na pewno powstanie coś nowego, może bazującego na Agile. Może stworzy to ktoś z młodszego pokolenia. Musimy poczekać kilka lat i się przekonać.
Dziękuję!
Photo by Jason Goodman on Unsplash
Skomentuj podcast