7 sierpnia 2019Agile

Mity zwinności

Jakie są mity zwinności? Nagraliśmy odcinek o nieporozumieniach, które przez lata nagromadziły się wokół agile’a. W odcinku poddaliśmy pod dyskusję najpopularniejsze z nich, które zgłosili nam nasi słuchacze.

Zobacz wersję wideo „Mity zwinności”

Dodatkowe materiały

Rola analityka w agile
Product Discovery
artykuł Czym jest agile? naszego autorstwa
artykuł „Czym jest Scrum” z serii Agile Starter na Agile247
Manifest Agile
Model Cynefin

TRANSKRYPCJA

Jacek: Jakiś czas temu zapytaliśmy was, jaki znacie popularne mity zwinności, dotyczące Agile’a i Scruma. W dzisiejszym odcinku przyjrzymy się pięciu najpopularniejszym mitom dotyczącym podejścia zwinnego. Będzie to odcinek, który nagrywamy w nieco innej formule. Będzie to odcinek krótszy niż zazwyczaj – będziemy celować z Kubą w 30 minut i zmienia się też równocześnie nasza częstotliwość wydawania podcastu. Dotychczas była to co trzecia środa, natomiast startując od dzisiejszego, siedemnastego już odcinka podcastu, chcemy release’ować ten podcast co dwa tygodnie.

Kuba: W przybliżeniu, bo zobaczymy, jak wypadnie okres świąteczny, ale spróbujemy trochę częściej, trochę krótsze nagrania.

Jacek: Dobrze, Kuba, jakie są te mity związane z Agile’em i z podejściem zwinnym?

Kuba: Wybraliśmy pięć spośród zgłoszonych przez poszczególne osoby. Nie opowiemy wszystkich, ale chcemy zacząć od takiego najbardziej związanego z podejściem zwinnym, czyli mit, że waterfall jest zawsze zły – konkretnie takie stwierdzenie nam podsunął Kamil. No i… Porządny Agile, podcast o Agile’u – czy waterfall zawsze jest zły?

Jacek: No tak, chyba powinniśmy powiedzieć, że tak właśnie jest.

[śmiech]

Kuba: W końcu jesteśmy zwinni, więc naszym naturalnym wrogiem jest waterfall.

Jacek: Tak, natomiast, moje takie główne przemyślenie, jak widzę tego rodzaju sformułowania, że coś jest zawsze jakieś, no to pierwsza myśl, która mi przychodzi do głowy, jest taka, że – co do zasady – nie wierzę w to, że istnieją perfekcyjne narzędzia, które rozwiązują wszystkie problemy, tak więc taki absolutnie pierwszy odruch, nie wchodząc w jakieś konkretne modele czy frameworki, mój pierwszy odruch jest taki – że nie. To nie jest tak, że waterfall jest zawsze zły.

Kuba: Na zasadzie – bo nic nie jest zawsze złe lub dobre, tak?

Jacek: Dokładnie tak.

Kuba: Mhm.

Jacek: Natomiast wchodząc głębiej, to myślę, że takim dobrym modelem, czy dobrym narzędziem, które pomaga znaleźć odpowiedź na to pytanie jest Cynefin. I osobiście bardzo często rozpoczynam szkolenia, które prowadzę – dotyczące podejścia zwinnego – właśnie od tego modelu, który definiuje pięć głównych domen, pięć głównych obszarów, które różnią się od siebie złożonością, czyli mamy obszar prosty, skomplikowany, złożony, jest też obszar chaotyczny i pośrodku Disorder, czyli obszar, w którym do końca nie wiemy, w jakim obszarze jesteśmy. I jeśli mówimy o tym obszarze prostym, gdzie istnieją najlepsze praktyki, gdzie istnieje superwidoczna zależność przyczynowo-skutkowa, no to to… problemy z tej domeny, moim zdaniem, mogą być rozwiązywane podejściem waterfallowym, czyli takim podejściem, gdzie jesteśmy w stanie sobie przeanalizować problem, zaplanować i po prostu go wykonać. No i szansa, że wydarzy się coś nieprzewidywalnego jest bardzo mała.

Kuba: Takie typowe waterfallowe nadaje się też do domeny skomplikowanej, gdzie też trzeba zaplanować sobie pracę, zrozumieć zjawisko, ten świat skomplikowany, to jest świat, w którym świetnie sprawdzają się eksperci, którzy już mają wiedzę, oni już wiedzą, jak to trzeba rozwiązać, tylko po prostu sprawie się trzeba głęboko przyjrzeć, zastanowić, przemyśleć alternatywy, dobrać różne jakieś rozwiązania czy metody, czy jakieś pomysły- spośród już istniejących dobrych praktyk – wszystko złożyć w jakąś ideę, plan – i po prostu to wykonać. I uzyskać spodziewany rezultat, bo tu nadal związek przyczynowo-skutkowy jest między „A, B i C łącznie dają nam D”, a ponieważ chcemy uzyskać „D”, no to trzeba wykonać te trzy wcześniejsze kroki, czyli takie też podejście planistyczne. Ta granica wynikająca właśnie z Cynefina tu ewidentnie leży na tym, czy jesteśmy w stanie wszystko wiedzieć, czy znamy już te rzeczy, które są nam znane oraz znamy te rzeczy, nad którymi się jeszcze musimy zastanowić, ale jest ich skończona ilość. Natomiast domena złożona – ten świat, który też się nadaje świetnie do Agile’a – a akurat podejście takie waterfallowe, planistyczne tam nie gra, no to to jest świat, w którym nie wiemy, czego nie wiemy. Czyli są jakieś zmienne czy jakieś takie… wymiary, w których po prostu nawet nie zdajemy sobie sprawy, bo nigdy tego nie robiliśmy, bo tak działa świat, bo taka jest historia, nie wiem, na rynku tak funkcjonuje nasz produkt, że są po prostu takie zmienne, których nawet nie zdajemy sobie sprawy, że wpływają nam na rezultat. I tu, ile byśmy nie planowali, to jesteśmy w stanie poplanować to, co wiemy, ewentualnie wpaść na to, czego na dzisiaj nie wiemy, ale wiemy, że jesteśmy w stanie tą wiedzę gdzieś znaleźć. Natomiast, no, świat złożony, świat, w którym Agile też się tak świetnie odnajduje, to jest ten świat, w którym po prostu rzeczywistość nas zaskakuje i nie ma tylu czynności planistycznych, które by nam te zaskoczenie jakoś zastąpiło.

Jacek: Przenosząc to, co mówimy, na taki życiowy przykład, to powiedziałbym coś takiego, że jeżeli inicjatywy, które realizujesz czy projekty, które prowadzisz, czy rzeczy, które budujesz, usługi, które świadczysz – jeżeli to są rzeczy superpowtarzalne, rzeczy proste, rzeczy w który jest bardzo mało miejsca na personalizację – robiłeś/robiłaś te rzeczy już dziesiątki albo setki razy, no to być może nie ma sensu na siłę szukać w tych obszarach przestrzeni na zwinność, ponieważ, no, tak niewielka ilość rzeczy jest w stanie ciebie zaskoczyć, po prostu to podejście, takie klasyczne, gdzie planujemy, wykonujemy i sprawdzamy, czy to jest to, co chcieliśmy, będzie po prostu wystarczające.

Kuba: Okej, idąc dalej, do kolejnego mitu – mit, który podsunęła nam Paulina – takie stwierdzenie: „Jak pracujesz zwinnie, to nie możesz zrobić porządnej analizy tematu przed rozpoczęciem pracy z zespołem, bo to jest waterfall”. Czyli, parafrazując trochę, jakakolwiek forma zastanawiania się przed uruchomieniem pracy z zespołem jest zakazana w Agile’u, czy też – tak patrząc jeszcze ostrzej – wytyczna: „Masz jakiś pomysł do działania? Natychmiast wrzuć to do zespołu i nie czekaj, nie zastanawiaj się, nie analizuj, bo wszystko inne niż natychmiast rozpocząć pracę, to jest zakazane w podejściu zwinnym”. Oczywiście jest to mit.

Jacek: Absolutnie. Ja myślę, że ten mit urodził się trochę na kanwie tego takiego… buntu, na zasadzie: w podejściu waterfallowym zwykle występowała po prostu wprost nazwana faza analizy, no więc skoro nie robimy waterfalla, a robimy Agile’a, no to przecież tej analizy nie ma, no bo analiza jest w Sprintach. I oczywiście jest to pewne uproszczenie, ponieważ masa tematów, obszarów, jakichś niuansów związanych z czymkolwiek, co wytwarzamy, wymaga zwykle jakiegoś zastanowienia się, przemyślenia, zbadania – być może zrobienia eksperymentu, zdobycia wiedzy – tak więc, z mojej perspektywy jest absolutnie okej, że możemy zrobić jakąś analizę przed rozpoczęciem prac, natomiast myślę, że tutaj to, co jest istotne, to jest to, ile czasu poświęcamy na tą analizę. Z mojej perspektywy ryzyko, które tutaj widzę jest takie, że możemy wpaść w pewien taki paraliż analityczny, na zasadzie: jeszcze wszystkiego nie wiemy, więc analizujemy, jeszcze nie wiemy, analizujemy, analizujemy, analizujemy, a być może już dawno osiągnęliśmy punkt taki „good enough”, w którym po prostu mamy już wystarczającą wiedzę, żeby wystartować, no i, jakby… dorabiać sobie, czy uzupełniać te braki analityczne, które odkrywamy już w trakcie prac zespołu.

Kuba: I myślę, że klucz to będzie, żeby każdy w zespole – czy może w firmie – znalazł sobie tą swoją definicję czy swoje zrozumienie tego „good enough”, o którym wspomniałeś, Jacek, przed chwilą, czyli: ile czujemy, że to jest wystarczająco, jakie czynniki są dla nas krytyczne, kluczowe, które nie pozwalają nam rozpocząć pracy, a jakie są takie, które możemy sobie równolegle realizować wraz z developmentem kolejnych przyrostów naszego produktu – również dookreślać czy doprecyzowywać czy to jakieś wymagania, czy jakieś zależności, czy jakieś jeszcze inne realia biznesowe, które mają tutaj znaczenie. To na pewno jest tak, że ten temat jest fascynujący, tak się akurat składa, że jego już trochę poruszaliśmy w odcinku ósmym, gdy mówiliśmy o roli analityka, gdzie tak naprawdę trochę się mocniej o tym rozgadaliśmy. Alternatywą do analizy takiej waterfallowej w Agile’u jest też na pewno faza Product Discovery – to konkretnie akurat opowiedzieliśmy w odcinku dziesiątym. W skrócie: jest masa technik, masa sposobów na to, żeby odkrywać, jaka jest faktyczna potrzeba pracować nad tym całym zespołem i też eksperymentować z kolejnymi wersjami swojego rozwiązania – od czegoś super prostego, co można szybko pokazać naszym klientom i przez kolejne jakieś iteracje doprecyzowywać czy dopracowywać rozwiązanie, które oferujemy na rynek.

Jacek: Kolejnym, trzecim, mitem, który chcielibyśmy dzisiaj omówić, jest mit, który brzmi: „Agile = Scrum”, czy „Agile to jest Scrum” – jest to mit zaproponowany przez Krystiana i rozumiemy go w ten sposób, że żeby być zwinnym, to musisz konkretnie korzystać z frameworka Scrum.

Kuba: Czyli, odwracając, jeśli nie korzystasz ze Scruma, to nie jesteś zwinny. Jeśli twój Scrum jest niedoskonały, to nie masz prawa być zwinny itd. itd. – wszystkie te alternatywy czy takie rozszerzenia tej myśli. No, wszystko to jest mitem – jak najbardziej można stosować podejście zwinne czy mieć zwinność w swoim produkcie czy zwinność w swoim projekcie, czy zwinność w swoim zespole. Nawet jeśli nasze podejście jest bliższe lub dalsze Scrumowi, ale jednak Scrumem już nie jest.

Jacek: Jasne. Biorąc sobie Scruma, patrząc na to, jak bardzo on jest Agile’owy, no to oczywiście czy pryncypia, czy pewne zasady, które stoją za Manifestem, można je odnaleźć w Scrumie, natomiast nie jest to jedyne narzędzie, nie jest to jedyny framework, przy czym myślę, że ten mit, on wynika z tego, że jeśli chodzi o popularność metod czy frameworków zwinnych, no to faktycznie jest tak, że ten Scrum jest najbardziej popularny, jest najszerzej rozpromowany, no i to po prostu widać. Ale też ogólnie dostępne ankiety czy badania zwinności wskazują na to, że Scrum + jego jakieś tam „mixy”, rozszerzenia, połączenia – chociażby z Kanbanem ostatnio popularny – powodują, że może on, w dużym uproszczeniu, stać się synonimem słowa „Agile”.

Kuba: Natomiast przez to Scrum może być punktem referencyjnym, ale pewne konkretne ścieżki, które w Scrumie zostały dookreślone, jako w metodzie, niekoniecznie są niezbędne, żeby wypełnić wytyczne z Manifestu. To jest długa historia, ale w skrócie, chociażby temat sztywnych Sprintów – no to Scrum mówi: „Sprinty są i przestrzegaj Sprintów”, no, Manifest zwinnego wytwarzania, w zasadzie zasady stojące za tym manifestem, mówią o tym, żeby dostarczać wcześniej często wartość i iterować z klientem, ale niekoniecznie np. trzeba się trzymać koncepcji Sprintu, bo być może wytyczną często dostarczać można poprzez rozwiązania bardziej przypominające Kanbana, czyli każdy feature, który mamy zrealizowany po prostu dostarczamy, wyrażamy, przekazujemy i np. w skrajnie „devopsowym„ zespole, no to jest to do zrobienia dosłownie w dzień, dwa, między pomysłem a wdrożeniem, co akurat już wymyka się idei Sprintu.

Jacek: Inny przykład to jest – w Scrumie mamy zdefiniowaną rolę Product Ownera, Manifest nic nie mówi o tej roli, mówi tylko o bliskiej współpracy osób biznesowych i developerów, no i sam miałem możliwość obserwowania takiej współpracy, gdzie Zespół Developerski jako punkt kontaktowy po stronie biznesowej dostał stakeholdera, który świetnie rozumiał temat, no i właściwie dosłownie codziennie zespół z tą osobą spędzali czas, próbując wzajemnie się zrozumieć. Czy był to Scrum? Nie był. Czy było to podejście zwinne? Było. Tak więc… tak to wygląda.

Kuba: Z ostatnich przykładów czegoś, o czym mówi Scrum, a niekoniecznie są wspominane w Manifeście, no to chociażby rola Scrum Mastera. Scrum, jakby tutaj dookreśla, że ten proces pracy, że ten framework będzie dobrze funkcjonować w momencie gdy będzie dedykowana osoba, gdzieś tutaj zarządzająca procesem, a podejście zwinne może również być możliwe, jeśli takiej osoby nie mamy, jeśli mamy tą odpowiedzialność za proces u wielu osób, u managera na przykład, no to to będzie ewidentnie antywzorzec scrumowy – jeśli tego Scrum Mastera nie ma albo on jest jakiś bardzo dziwacznie zorganizowany – ale całkowicie możliwe i widziałem takie przypadki zespołów, które były zwinne, miały jakiś swój własny proces, niekoniecznie były to Scrumowe, i faktycznie nie istniał Scrum Master – musielibyśmy bardzo długo taki wysiłek umysłowy robić, żeby sobie przetłumaczyć to, co się dzieje w tym zespole – nie wiem, rola lidera na przykład – na to, że wypełnia rolę Scrum Mastera. No i albo możemy się bawić w myślowe tłumaczenie albo po prostu sobie głośno powiedzieć: „Scrum wymaga Scrum Mastera, Agile jest możliwy bez konieczności funkcjonowania jakiejś dedykowanej roli opiekuna zwinności”, jakkolwiek byśmy sobie to uogólnili.

Jacek: Z mojej perspektywy Scrum, jako taki framework dosyć deskryptywny, który i definiuje rolę, i artefakty, i wydarzenia, jest po prostu prosty do zrozumienia i do zastosowania, bo na bardzo wiele takich niejasności płynących z Manifestu mamy bardzo gotowe odpowiedzi, czyli przykładowo: w Manifeście mówimy o szukaniu lepszych sposobów pracy, o usprawnianiu się – no to zamiast zastanawiać się, jak to zrobić, no to przychodzi Scrum i mówi: „Oto Retrospektywa, robisz ją na końcu Sprintu i efektem jest to i tamto”. Tak więc… kompatybilne podejścia, jakby, czuję, że oboje rozumiemy, z czego to wynika, natomiast, co do zasady, można być zwinnym niekoniecznie korzystając z frameworka scrumowego.

Kuba: I bardzo ciekawa kwestia jest taka, jeśli jesteśmy w ramach dyskusji „czy Agile jest scrumowy” albo „czy Scrum to jedyna metoda zwinna”, warto pamiętać, że Scrum został stworzony wcześniej niż napisany został Manifest zwinnego wytwarzania oprogramowania, co też dosyć ładnie sygnalizuje, że metoda istniała wcześniej niż kiedykolwiek ktoś nazwał czy spisał to, czym jest zwinność.

Jacek: Czwartym mitem, o którym chcielibyśmy dzisiaj porozmawiać, jest to mit, który zgłosiliśmy samodzielnie z Kubą do odcinka, to jest mit brzmiący następująco: „Agile to SAFe bądź Spotify model”. Jest to bardzo podobny mit do mitu, o którym mówiliśmy przed chwilą, natomiast z naszej perspektywy pracy jako konsultanci zewnętrzni, jest to taki mit, który pojawia się bardzo często na poziomie organizacji, gdzie – tak w dużym skrócie – cała dyskusja na temat tego, czym jest zwinność, po co nam zwinność, jaka motywacja stoi za tym, że w ogóle chcemy wejść na ścieżkę zmieniania się, jest spłycana do gotowca na zasadzie, przykładowo: dzielicie firmę na „chaptery”, inne tam…

Kuba: Tribe’y.

Jacek: Tribe’y, które opisał Spotify jako sposób, w którym pracowali – no to to jest takie uproszczenie, z którym bardzo trudno jest nam się zgodzić i uważamy, że warto poświęcić parę minut na omówienie tego przypadku.

Kuba: I tak jak dookreśleniem Agile’a jest Scrum, tak dookreśleniem tego, jak zwinna organizacja mogłaby wyglądać – faktycznie są takie modele jak Scaled Agile Framework czy model opisany przez Henrika Kniberga w tych filmikach o Spotify – ale, no, to to jest niebezpieczne uproszczenie czy niebezpieczne dookreślenie. Tak jak każda firma wypracowuje sobie swoje specyficzne praktyki, które mogą zależeć od takiego ogromu rzeczy, jak chociażby rynek docelowy – czy jesteśmy B2B czy B2C? Jak, chociażby, skala obsługi klientów – czy lokalnie, czy jakoś na cały kraj, czy w ogóle międzynarodowo? Skąd w ogóle przychodzą pomysły, jakie mamy produkty, jak stare mamy produkty, jak bardzo elastyczne platformy dostarczania naszych rozwiązań? Te wszystkie rzeczy takie bardzo rynkowe, tak bardzo wpływają też na to, jak zorganizowane są projekty czy inicjatywy produktowe, czy jakieś formy decydowania o tym, co jest priorytetowe, jaki mamy długi cykl od pomysłu do wdrożenia, jak długi mamy cykl życia naszego produktu – cała masa rzeczy, które powodują że procesy zarządzania organizacją, procesy zarządzania zespołami po prostu naprawdę muszą być dopasowane do organizacji i coś, co działa w jednej firmie na pewno nie zadziała w innej firmie.

Jacek: Albo co najmniej rezultaty będą inne, bo wspomniałeś o tych wszystkich czynnikach takich biznesowych, ale też, z mojej perspektywy, takim bardzo wrażliwym aspektem jest nasza aktualna kultura organizacyjna, sposób, w jaki management pracuje z ludźmi, kultura informacji zwrotnej – wszystkie te aspekty są superwrażliwe. Każda firma jest na innym poziomie rozwoju i teraz założenie takiej czapki unifikującej każdą firmę do poziomu jakichś tam elementów określonych czy w SAFe czy w Spotify, no, jest superdużym uproszczeniem i naiwnością z mojej perspektywy jest zakładanie, że nałożenie takiej „czapki” da nam efekty obiecywane przez Agile’a, czyli przez podejście zwinne. Niestety sam mam takie doświadczenie, taką historię, w której to prezes firmy, z którą współpracuję, opowiedział mi jak pojawił się na konferencji Agile’owej i wszedł w dyskusję z konsultantem z bardzo dużej grupy konsultingowej, no i jakby tak spłycając tą dyskusję, którą odbyli, no to… konsultant większość czasu spędził na przekonywaniu prezesa, że „Aha, to skoro chcecie być zwinni, no to jest taki gotowy model, który my wdrażamy z sukcesem, no i ten model to jest Spotify”, tak więc… Łza się w oku kręci, jak się takie historie słyszy.

Kuba: I tak jak jest anegdotycznie „prawda czasu” i „prawda ekranu”, prawda? No to wielu z naszych słuchaczy dzieli się z nami historiami, jak może jest odległy świat ten konsultingowy od tej rzeczywistości, czy też takie powiedzonko, że „PowerPoint wszystko przyjmie” i „W Excelu wszystko wygląda ładnie i dobrze”, no i to jest ten świat, w którym tak naprawdę mamy do czynienia raczej z jakąś formą sprzedaży, takiego fałszywego marketingu, że kolejnym firmom obiecuje się złote góry pod bardzo przyjemnym hasełkiem Agile’a, akurat elegancko też rozpoznawalną marką firmy Spotify, no ale później się rozmawia z ludźmi ze Spotify i oni sami osobiście odradzają innym firmom, są zupełnie gdzie indziej obecnie, jeśli chodzi o swój sposób funkcjonowania, a nawet jeśli sami stosują coś w miarę podobnego do tego, co już ładnych parę lat temu zostało w tym filmiku opowiedziane, to to też ma swoje wady, które raczej nie są w tym filmie wspomniane. Na pewno większość organizacji, które obecnie mają ten model sprzedawany, mają bardzo różną sytuację i powinny raczej, jako alternatywę, powinny sobie wypracowywać swoje własne podejście, popróbować zrobić dobrze zwinność na poziomie poszczególnych zespołów, poćwiczyć, jak to się robi w skali kilkuzespołowej. Być może absolutnie okej jest też ten taki okres przejściowy, w którym mamy fajne zespoły scrumowe czy fajne zespoły zwinne rozwijające jakieś wybrane produkty czy nawet całą pulę produktów, ale niekoniecznie jeszcze idealnie poukładane w jakieś docelowe plemiona, drużyny czy jakiekolwiek inne etykiety sobie tam wymyślimy. Ostatnim mitem, który chcemy poruszyć w ramach tego odcinka jest temat, który również sami wymyśliliśmy, sami sobie zgłosiliśmy do swojego własnego Backlogu, to temat, że „Agile to jest podejście właściwe wyłącznie do IT, a nawet jeszcze bardziej wąsko patrząc – że to jest podejście właściwe do rozwoju oprogramowania i nie ma zastosowania w innych miejscach, do których należy stosować zupełnie inne podejścia, bardziej poważne, np. zarządzanie projektami” albo po prostu „Nie należy stosować podejścia zwinnego, bo jest nieadekwatne”.

Jacek: Ja bardzo często słyszę ten mit – czy to na wczesnym etapie rozmów z klientami, czy to podczas jakichś warsztatów i szkoleń, na zasadzie: „No tak, ale przecież te wszystkie rzeczy, o których tutaj pan opowiada, no to one działają dla IT, natomiast my tutaj nie mamy w ogóle IT, no i co w tym przypadku?”. No i tak: co do zasady, jeśli mówimy o Manifeście, no to faktycznie, patrząc na skład osobowy osób, które podpisywały Manifest, wyłapując bardzo konkretne wyrazy czytając Manifest – no to, jakby, zgoda jest taka, że to się wyłoniło ze świata IT, natomiast bardzo niewielkie modyfikacje Manifestu czy ogólnie po prostu przyjęcie pewnego sposobu myślenia, jak możemy funkcjonować, jak możemy działać są absolutnie uniwersalne, czyli przykładowo: usprawniać cyklicznie możemy się niezależnie od tego, czy robimy rozwój produktu cyfrowego czy budujemy firmę kompletnie nie IT. Zespoły cross-funkcjonalne możemy budować w firmach niezależnie od posiadania działu IT itd. Przykłady można mnożyć i też na bazie naszych doświadczeń z Kubą, tak jakbym sięgnął pamięcią, to moje dwa ostatnie dłuższe kontrakty z klientami, to są kontrakty z firmami, które nie są firmami IT. I, no, z powodzeniem testujemy, używamy, eksperymentujemy i z podejściem zwinnym jako takim i ze Scrumem, no i z całą gamą innych różnych podejść, które można byłoby powiedzieć, stworzone są dla świat IT, natomiast w praktyce okazuje się, że wcale tak nie jest.

Kuba: Dokładnie ta, wręcz z rozrzewnieniem się uśmiecham jak właśnie na szkoleniu ktoś mnie pyta w jakiejś trzeciej firmie: „No, ale to jest fajne podejście, czy się nadaje do IT?”, a półtora roku mojej pracy to głównie podejście zupełnie poza IT, gdzie tworzymy nowe usługi, tworzymy jakieś rozwiązania procesowe, zmieniamy sposób funkcjonowania firmy, która albo ma bardzo małą składową IT, albo w danym projekcie kompletnie nie zmieniamy nic w tych systemach. Ciekawostką tutaj może być też odpowiedź Jeffa Sutherlanda na tego typu pytanie: „Czy Agile może być zastosowany, czy w tym przypadku Scrum może być zastosowany poza IT?”. No to w miarę świeżą odpowiedź niedawno zauważyłem w Internecie, gdzie Sutherland, czyli współtwórca Scruma, mówi: „80% mojego czasu, zaangażowania oraz moich ludzi z mojej firmy konsultingowej, to są obecnie projekty nie-IT albo projekty, w których ta IT nie jest główną składową”. Bo tak naprawdę ten mindset, też tych kilka wytycznych nadaje się świetnie do dowolnego typu produktu czy dowolnego typu usługi, jeśli ta usługa czy produkt ma problemy ze złożonej domeny i jeśli rozwijane są przez organizację jakimś zespołem. No to tak naprawdę jeśli tylko zamienimy słowo „oprogramowanie” w Manifeście na słowo „produkt”, „usługa” albo „wartość dla klienta”, to cała reszta wytycznych jest bardzo dobra. Podoba mi się też taki tekst Steve’a Denninga, że: „Możliwe, że Agile, czy te metody zwinne mają ten problem, że pochodzą od niewłaściwych ludzi”. W wielu organizacjach IT nie ma do końca pozytywnego skojarzenia, że to się kojarzy z „head deskiem”, z ludźmi, którzy zawodzą, z systemami jakimiś enterprise’owymi, które są ociężałe i nie za fajne, no i nie każdej firmie i nie w każdym biznesie może się kojarzyć, że ludzie, którzy są odpowiedzialni za Enterprise IT są w stanie wymyślić nowe, fajne metody zarządzania, fajne metody rozwoju produktu czy po prostu metody, no, skracania cyklu, informacji zwrotnej między odbiorcą docelowym a zespołem, który wykonuje jakieś działania.

Jacek: No to tutaj chyba tylko dołożę jeszcze komentarz, skoro wspominasz Sutherlanda, czyli współtwórcę Scruma, że przewodnik po Scrumie, czyli takie, no, oficjalne… oficjalna broszura opisująca Scruma – tam też nie znajdziesz niczego, co by wskazywało na to, że jest to framework do rozwiązywania problemów związanych z IT. Tam jest ewidentnie mowa o produkcie, o rozwiązywaniu problemów, które są złożone, o rozwiązywaniu tych problemów w kreatywny i efektywny sposób. Natomiast jakie to są problemy, no to tak naprawdę to zależy od nas.

Kuba: I jak przygotowywaliśmy to nagranie, to dużo wątków nam się nasuwało jako kandydaci na kolejne odcinki – „Agile poza IT”, czy wykorzystanie Agile’a szeroko do rozwoju produktów czy rozwiązywania problemów biznesowych jest żelaznym kandydatem na kolejne nagranie, zdecydowanie nie czujemy, że tutaj wyczerpaliśmy temat, chcemy tylko podkreślić – jest to ewidentnie mit związany z Agile’em, że Agile jest tylko dla IT. Podsumowując ten odcinek – opowiedzieliśmy tobie pięć największych, naszym zdaniem, mitów dotyczących zwinnego podejścia. Waterfall nie zawsze jest zły, w zwinnym podejściu możliwe są działania analityczne, nawet jeśli nie jest to klasyczna faza analizy z waterfalla. Można realizować podejście zwinne w inny sposób niż z wykorzystaniem podejścia scrumowego. Zwinna organizacja niekoniecznie musi wzorować się na podejściu z SAFe’a albo być identycznie poukładana jak Spotify, a Agile jest podejściem, które ma swoje korzenie w świecie IT, ale świetnie sprawdza się również w projektach organizacyjnych, biznesowych, do rozwoju produktów czy usług.

Jacek: Na koniec chcielibyśmy zaprosić cię na konferencję Management 360, która odbędzie się 24. i 25. października 2019 roku. Będziesz tam miał, bądź miała okazję spotkać zarówno mnie, jak i Kubę osobiście, poprowadzimy razem z Kubą warsztat, który nazwaliśmy „Porządny Agile”, na stronie management360.pl możesz zapisać się na ten warsztat oraz dodatkowo podzielę się swoimi przemyśleniami w formie prelekcji na temat moim zdaniem najpopularniejszych, najpoważniejszych pułapek związanych ze zwinnymi transformacjami.

Kuba: Przypominam też o toczących się zapisach na warsztat „Prawdziwe przypadki scrumowe”, który odbędzie się 16. i 17. września w Warszawie. Nadal są jeszcze wolne miejsca, razem z Dawidem Lewandowiczem przepracujemy najciekawsze, najtrudniejsze przypadki i wypracujemy rozwiązania, które można wykorzystać w swoich własnych zespołach.