W tym odcinku podkastu dzielimy się refleksją, jak wygląda aktualny stan zwinności w Polsce, zainspirowani artykułem Martina Fowlera „The State of Agile Software in 2018„. Na bazie naszych doświadczeń, komentujemy postępującą komercjalizację zwinności, rolę doskonałości technicznej w byciu zwinnym oraz główne różnice w pracy produktowej i projektowej.
Zobacz wersję wideo
Bezpłatną konsultację kierujemy do osób zarządzających technologią lub produktem w średnich i dużych firmach, które mają pod sobą co najmniej kilka zespołów wytwarzających. Rozmowa trwa zwykle 45 minut, które możesz wykorzystać na skonsultowanie ważnego dla Ciebie tematu związanego z procesem dostarczania produktów cyfrowych.💡 BEZPŁATNA KONSULTACJA DLA LIDERÓW 💡
Porozmawiajmy o efektywności w Twojej firmie!
Dodatkowe materiały
- Wystąpienie Marina Fowlera – „The State of Agile Software in 2018” (video)
- Transkrypcja wystąpienia Martina Fowlera – „The State of Agile Software in 2018” (tekst)
- Wartości oraz zasady Manifestu Zwinnego Wytwarzania Oprogramowania
Transkrypcja podcastu "Stan agile w 2018 roku"
Jacek: W dzisiejszym odcinku chcemy spróbować z Kubą trochę innej formuły niż zazwyczaj. chcielibyśmy porozmawiać, właściwie skomentować tak naprawdę bardzo wartościowe wystąpienie Martina Fawlera które nazywa się „ The State of Agile Software in 2018 ”.Chcielibyśmy podzielić się naszymi refleksjami , naszym spojrzeniem na tematy które w swojej prezentacji poruszył Martin.
Kuba: Obaj, do tego wystąpienia dotarliśmy poprzez transkrypcję na stronie Martina. W podpisie odcinka jest link do tej treści. Nie chcemy w samym odcinku opowiadać co jest w treści, po prostu zachęcamy do tego, żeby to przeczytać jeśli jeszcze tego nie zrobiłeś. Natomiast chcemy skomentować i nawiązać do wątków, które Martin poruszył. Faktycznie uznajemy je za istotne i godne tego, żeby trochę się w nie zagłębić.
Jacek: Trzy główne tematy, które poruszył to są przede wszystkim Agile Industrial Complex, czyli temat tego, w jaki sposób aktualnie dzisiaj Agile jest implementowany, używany, wdrażany i wykorzystywany w firmach. Drugim dużym obszarem to jest obszar doskonałości technicznej, czyli w jaki sposób Agile powiązany jest z tym jak deweloupujemy software i w jaki sposób. Trzeci ostatni temat dotyczy różnicy między orientacją pracy wokół projektów a orientacją pacy wokół produktów.
Kuba: Zacznijmy od tego co nazwane tutaj zostało Agile Industrial Complex. To jest dosyć pojemne hasło. Z jednej strony Martin tam mocno porusza wątek rozwoju tej branży, czy tej dziedziny związanej z tym jak Agile jest wspierany, jak jest rozwijany, jak jest uczony. Tutaj jest wątek, powiedzmy, całego biznesu, jaki się zrodził w dziedzinie, która na początku była raczej domeną kilku autorów książek, raczej takich mniejszych consultingów. Teraz jest to po prostu gigantyczny ogólnoświatowy biznes. Jest też jakby druga strona, czy druga noga tego samego wątku. To też jest coś takiego, że coś, co pierwotnie było raczej pewną filozofią, pewnym nurtem, pewnym nowym spojrzeniem na rozwój oprogramowania, zamieniło się przez bieg ostatnich lat w coś, co jest procesem pracy. Procesem przez Martina wręcz mocno nazywanym procesem, którym zajęli się kierownicy projektów i zastąpili stare metody zarządzania projektami nowymi metodami zarządzania projektami. Chcemy poruszyć oba te wątki. Myślę, że nie będziemy się za mocno skupiać na tym wątku Agile’a jako biznesu, ale od tego chcemy zacząć.
Jacek: Tak, generalnie jak tak słuchałem tego co opowiadasz to myślę, że z jednej strony żyjemy w fajnych czasach, bo dostęp do wiedzy czym jest podejście zwinne jest właściwie nieograniczony. Konferencje, spotkania sami jesteśmy teraz w drodze na Agile Coach Camp, polską edycję. Tak więc właściwie jakby się dobrze postarać to w każdy weekend czy w każdym tygodniu można znaleźć miejsce, gdzie ludzie rozmawiają o tym jak pracować zwinnie. Także dostęp do wszelkiego rodzaju publikacji jest właściwie nieograniczony. Co więcej, często bez problemu możemy dostać, w szczególności drogą elektroniczną bardzo szybko publikacje, które są w języku ojczystym. W sensie najczęściej te publikacje wychodzą po angielsku tak więc nie jest to tak jak kiedyś, że ta wiedza jest tajemna, że jest pochowana, że niewiele osób w Polsce ma dostęp do jakiejś tam publikacji czy ma jakiegoś PDFa z czymś, więc na pewno jest to pozytywny aspekt. Natomiast druga strona tego medalu jest taka, że faktycznie to pojęcie zwinności trochę się „wyświechtało”, że tak powiem. Właściwie dzisiaj kogo by nie zapytać, to pracuje w zwinny sposób i właściwie nie ma firm, które by nie deklarowały, że 'tak, używamy Scruma, tak pracujemy zwinnie”. Właściwie nie ma się do czego przyczepić.
Kuba: Tu jest taka moja osobista myśl, ale Jacek pewnie masz identyczne doświadczenie, że raptem w parę lat jesteśmy w stanie zaobserwować coś takiego, że Agile gdzieś tam się dopiero w Polsce zaczynał, na początku tej dekady, a po paru latach to jest w miarę oczywiste, że we wszystkich firmach IT ten Agile jest i coraz bardziej się popularyzuje poza IT. Sporo takich wątków Agile’a poza IT, Agile’a w biznesie, Agile’a do projektów niesoftware’owych, to jest temat bardzo modny. Czaimy się, czaimy, ale ja to powiem wprost. Teraz niby jest moda, niby jest popularność, ale jednocześnie oprócz tych fajnych, dobrych rzeczy jak dostępność widać też, że coraz więcej osób zaangażowanych w temat Agile jest jednak skupionych na tych aspektach biznesowych. Sprzedać kolejne szkolenie, wystawić kolejny certyfikat, robić to po prostu z racji tego, że to jest zawód i to jeszcze dodatkowo dobrze płatny albo biznes, na którym można dobrze zarobić. I to jest coś, co też widać na przykład w firmach szkoleniowych. Każda firma szkoleniowa ma w ofercie coś o Agile’u. Mało która firma ma w ofercie o Agile’u coś, gdzie jest ujawniony trener, bo to po prostu nie jest osoba, która ma cokolwiek z Agilem wspólnego, tylko to jest po prostu zawodowy trener. Wczoraj uczył Prince2, dzisiaj uczy Agile, jutro będzie szkolił z zasad udzielania feedbacku. W ramach tej popularyzacji Agile został wyświechtany, czy też zdewaluowany do procesu pracy, sposobu działania w projektach. To jest w ogóle nie ten kierunek. Zwłaszcza, zakładam, że osoby, które czują, że coś jest z tym nie tak, każdy z nas z osobna może z tym coś zrobić. Może coś zrobić wewnątrz swojej firmy, wewnątrz swojego zespołu. Może starać się propagować tą właściwą, pogłębioną wersję zwinnego podejścia, niekoniecznie dewaluować czy wskakiwać do tego ślepego pędu ku procesyzacji, standaryzacji czy takiego biznesowego podejścia do zwinności.
Jacek: To, co mi osobiście się sprawdza ostatnimi czasy, to jest wracanie do manifestu, czyli wracanie do tych czterech podstawowych wartości, które są zdefiniowane. Natomiast jakby idąc dalej bardzo dużo można wyciągnąć z dwunastu zasad, które kryją się za tymi czterema wartościami. Bardzo fajne ćwiczenie, które sobie kiedyś zrobiłem na potrzeby jednego z warsztatów to było zamapowanie zależności pomiędzy wartościami, pryncypiami, konkretnymi technikami zwinnymi, z frameworkami które je reprezentują. Mi osobiście to bardzo pomogło lepiej i czytelniej sobie te wszystkie kropki połączyć. Z drugiej strony doprowadziło do tego, że dziś jestem bardzo uważny na sformułowania w stylu „My to robimy bo jesteśmy zwinni” albo „Robimy tak, bo to jest scrum”. Oczywiście częściej niż rzadziej to jest scrum, to np. estymujemy w story pointach, bo to jest scrum. To nie jest scrum, prawda? Przykłady można by mnożyć natomiast myślę, że to co ja mogę zrobić, Ty możesz zrobić to możemy przekładać trochę to skupienie i ciężar rozmów właśnie róbmy taką czy taką technikę, jednak bardziej na to jakie wartości są pod spodem i tak naprawdę co chcemy uzyskać. Myślę, że to jest jakby clou problemu.
Kuba: Za tym też się kryje coś takiego co nazywane jest cargokultem. Kultem cargo po polsku, żeby było w dobrej kolejności. Jakieś takie ślepe kopiowanie pewnych metod, pewnych wzorców, bo gdzieś, komuś, kiedyś coś takiego się sprawdziło. Najbardziej agresywnie do sprawy podchodząc w pewnym sensie kultem cargo jest nawet konkretnie wykorzystanie Scruma. Mówię, że agresywnie, bo obaj z Jackiem Scruma zarówno jakby praktykujemy jak i jakby propagujemy w firmach, to mimo wszystko nawet Scrum jest takim objawem próby kopiowania. W pojedynczym zespole prawdopodobnie jest spora szansa, że ten framework ma szansę się udać, natomiast mnie się samemu włos jeży na głowie, gdy słyszę o kolejnych firmach np. z branży finansowej, która jest mi znana również z racji mojego osobistego doświadczenia pracy w mBanku. Kolejne firmy finansowe są zachwycone pomysłem wdrażania modelu Spotify. W innych firmach jakieś gotowe wzorce skopiowane czy przyniesione przez jakieś firmy konsultingowe i to dawno zatraciło już ten charakter, który gdzieś zawarty jest również właśnie w zasadach stojących za manifestem zwinnego wytwarzania oprogramowania, żeby budować zespoły, żeby te zespoły składały się ze zmotywowanych osób, żeby one były skupione na samoorganizacji, żeby one współpracowały ze sobą w środku i z biznesem, poprzez komunikację twarzą w twarz. Wiele tych kolejnych modeli, wiele tych kolejnych gotowych wzorców czy rozwiązań kompletnie gubi te aspekty, za to bardzo uwypukla jakieś szczegółowe praktyki, które mogą być dobrą inspiracją, jakimś tam punktem do dyskusji, ale w szczególności nie powinny być stosowane jako gotową odpowiedź na to, jak sobie poradzić z jakimś tam szczegółowym aspektem typu współpraca Product Ownerów. To są rzeczy, które są trudne i to są rzeczy, które powinny w wielu firmach ewoluować, ale zgodne ze zwinnym podejściem będzie raczej podejście „Spróbujemy czegoś, najlepszego, na co nas stać i będziemy to ewoluować”, a nie odwrotność tego co widać, w wielu organizacjach. Tu mamy tutaj mądrego pana konsultanta, który nam dokładnie powie, jak to powinno wyglądać i my musimy po prostu przestrzegać tych konkretnych 17 kroków.
Jacek: Częste przykłady kultu cargo jak mówisz to Codzienny Scrum. Spotyka się grupa osób na 15 minut, spotkanie ma bardziej formę statusu jeśli by się zapytać uczestników na koniec, czy jakąś wartość mieli z tego spotkania, to zwykle nie ma, no bo tak naprawdę mało kogo interesuje enigmatyczna wypowiedź kolegi po prawej, czy po lewej stronie. Natomiast czemu to robicie, no bo robimy Scruma. To jeden przykład, inny przykład to jest używanie Scruma jako procesu, frameworka, który wspiera wytwarzanie w zespołach, które są zespołami komponentowymi, czyli produktem tego zespołu tak naprawdę jest półprodukt, który dopiero gdzieś tam trzeba zintegrować z masą innych zespołów. Patrząc z boku…
Kuba: Scrum analityków na przykład
Jacek: Tak. No robimy pięknego Scruma, natomiast nie można powiedzieć, że ten produkt jest używalny na koniec iteracji. Niestety tak to często wygląda.
Kuba: A co można zrobić, żeby się z tego wątku wyrwać? Coś, co wspomnieliśmy już to wracanie do manifestu, do jego pryncypiów. Wracanie do wartości stojących za manifestem i to jest coś co powinno ciągle wracać. Czy ten Scrum, którego używam jest zgodny z wartościami stojącymi za manifestem, innymi słowy czy mój Scrum jest zwinny? Tą definicją zwinności nie jest deklaratywna zwinność, albo umiem zrobić szpagat, więc jestem zwinny, tylko zwinność jest wtedy jeśli jestem zgodny z tymi wtedy spisanymi zasadami. One oczywiście nie pokrywają absolutnie wszystkich aspektów i można się bawić w akademickie dyskusje czy jest firma zwinna ta, która ma kilkumiesięczne iteracje, bo gdzieś tam, kiedyś w 2001 roku ktoś to tak zapisał, ale czy w moim Scrumie jest faktyczna samoorganizacja, czy w moim Scrumie faktycznie się komunikujemy, czy się adaptujemy, czy jesteśmy otwarci na zmiany. To są wszystko takie rzeczy, które nagle robią różnicę i tę różnicę może szczególnie zrobić taki aspekt, który w manifeście w zasadach zwinnego wytwarzania oprogramowania jest zawarty i to musi być traktowane łącznie.
Kuba: Często na szkoleniach jak pracuję z całym zespołem projektowym, czy z całą grupą rozwijającą jakiś produkt programistów to jak przechodzimy przez zasady, to momentalnie wytwarza się gigantyczna dyskusja, gdy dochodzimy do tego punktu, w którym jest coś o tym, że faktyczną zwinność zespoły uzyskują wtedy gdy dążą do technicznej doskonałości. Wtedy jest wielkie pytanie co to jest w ogóle ta techniczna doskonałość, jak to możliwe, że Agile manifest mówi o zwinności wtedy gdy ta doskonałość techniczna jest, a coś, co jest taką codziennością wielu członków zespołów projektowych, to jest to, że pędzimy. Owszem software na koniec każdego sprintu i może nawet jakiś tam Definition of Done, definicja ukończenia jest wypełniona, a tak naprawdę to nie ma nic wspólnego z tym jak zwykły szary człowiek, z zespołu projektowego by definiował swoje rozumienie technicznej doskonałości.
Jacek: Generalnie myślę, że cały manifest się narodził bardziej po stronie IT niż po stronie biznesowej i te główne wartości wyrażone w manifeście czy nawet konkretne zasady, no je możemy traktować bardzo ogólnie, patrząc na to jak chcemy pracować, ale właściwie większość z nich można przełożyć bardzo konkretnie na to, jak obchodzimy się z kodem. Tak jak mówiłeś, że firmy mówią o sobie, że są zwinne, a tej zwinności im brakuje, no to takim najczęściej spotykanym przeze mnie przejawem braku zwinności jest to, że na dzień dzisiejszy sposób, w jaki wytworzone jest oprogramowanie na zasadzie architektura, w sposób jak te wszystkie elementy tego produktu, patrząc od strony czystego kodu są poukładane, sposób konfiguracji tego produktu techniczny po prostu nie pozwala na to, żeby w zwinny i łatwy sposób przeprowadzać zmiany. Zwykle wynika to z tego, że kolejne nowe funkcjonalności produktu, kolejne zmiany nakładane są najczęściej pod presją czasu, więc to są takie rozwiązania bardzo prozaiczne, albo takie bardzo niezgodne ze sztuką wytwarzania oprogramowania. To jest jeden aspekt, natomiast drugi aspekt jest taki, że bardzo często brakuje czasu, albo może mówiąc szerzej brakuje zrozumienia. Jeżeli faktycznie chcemy być zdolni do szybkich zmian od strony technicznej , to musimy sobie ten nasz kod przebudowywać, refaktoryzować i doprowadzać do takiego stanu, w którym kolejne zmiany możemy zrobić w bardzo łatwy sposób. Może skomentuje tylko co to jest refaktoryzacja dla osób, które nie miały kontaktu z developmentem. Refaktoryzacja polega na tym, że nie zmieniając tego, w jaki sposób działa produkt my zmieniamy go od wewnątrz. Zmieniamy struktury, zmieniamy sposób zaprojektowania rozwiązania tak, aby kolejne zmiany były łatwe, możliwe i żeby nie było problemu takiego, że teoretycznie chcemy zrobić prostą, małą zmianę, chcemy dorzucić, powiedzmy nowe pole do naszej aplikacji, ale okazuje się patrząc w kod, że tam jest jedna wielka kula błota, wszystko jest ze sobą powiązane i zmiana w jednym punkcie powoduje, że tak naprawdę rozsypują nam się kolejne kawałki produktu.
Kuba: Ta techniczna doskonałość, jest czymś, co zrozumieć i potrzebować muszą członkowie zespołów, ale to jest też coś, co jakby świadomość istnienia tego tematu powinien mieć zarówno właściciel produktu jak i cała grupa manegementu, interesariuszy powyżej czy obok zespołów scrumowych na przykład. Tutaj używana jest metafora długu technologicznego. Oddzielna kwestia jak różne osoby to rozumieją, jak różnie sobie to można definiować, natomiast ta metafora ma o tyle dobre skojarzenia zwłaszcza dla świata finansowego, że dług technologiczny to jest kredyt, to jest dług. Jak każdy kredyt trzeba go spłacać z odsetkami. I takie fajne hasło, które kiedyś zobaczyłem na Twitterze, to nie jest kredyt w banku na parę procent, to jest kredyt u mafii, albo jakieś takie pożyczki chwilówki ze słupa ogłoszeniowego, że tam płacisz RRSO 300 %. W tym sensie, że każde słabe rozwiązania jakościowe wracają do zespołu, wracają do projektu, wracają w produkcie wcześniej, niż się wszystkim wydaje i usunięcie ich jest o wiele trudniejsze niż ktokolwiek by sobie to zaplanował, zwłaszcza taki nie-techniczny przedstawiciel jakiejś organizacji np. jakiś manager biznesowy. Więc to jest coś takiego, że nie ma dróg na skróty. Jeśli gdzieś jakieś rozwiązanie jest zrobione w słabej jakości, to błyskawicznie to wróci. Ten produkt będzie miał błędy, będzie się psuł, ten produkt będzie psuł się klientowi w rękach. Techniczna doskonałość musi być nawet jeśli z tego powodu jest wrażenie, że będzie trochę wolniej. Tu jest taki paradoks, że teraz będzie trochę wolniej, ale będziemy w stanie utrzymać tempo, a rozwiązanie będzie w dobrej jakości, która też wiąże się z dobrą wartością dla klienta. Możemy na chwile przyspieszyć obniżając jakość, niestety ani to za wiele przyspieszenia nie będzie z tego powodu, a potem już będzie tylko wolniej. To jest coś w stylu żyłowania się ponad wysiłki ludzkie, czy ponad wysiłki organizmu. Teraz sobie niszczymy organizm i już nigdy w życiu nie będzie lepiej bo na przykład pozrywaliśmy sobie ścięgna i już zawsze będziemy kuleć, bo myśleliśmy, że przez chwilę będziemy w stanie troszkę przyspieszyć, szybciej pójść do przodu.
Jacek: Wiesz co, moja obserwacja jest taka, że czasami trochę brakuje asertywności. Asertywności w rozumieniu, że pewnych rzeczy nie możemy od strony technicznej zrobić w zły sposób. Idąc dalej, w sensie możemy, ale to jest pewien koszt. To jest pewien dług. I tak będziemy ten koszt ponieść i tak będziemy musieli ten dług spłacić i pół biedy jeżeli faktycznie jest tak, że pod jakaś tam presją biznesową, bo chcemy coś dostarczyć na rynek bardzo szybko, no te rozwiązania nie są idealne, no to pół biedy jeśli faktycznie jest czas, żeby to naprawić w kolejnych iteracjach czy jakby sukcesywnie krok po kroku. Gorzej, jeśli jest to proces wiecznego zaciągania długu i nigdy niespłacania go. Wracając do tej asertywności, no to sam byłem developerem 7 lat i wiem, że to nie jest proste, ale gdy dzisiaj myślę sobie o profesjonalnym developerze, to widzę w takiej osobie, taką zdolność do powiedzenia, że nie. Jeżeli oczekujemy od strony IT, że będzie dostarczać rozwiązania wysokiej jakości, to nie możemy wchodzić na warsztat i mówić słuchaj, tego narzędzia nie używaj, tego nie rób w ten sposób. Jeżeli ja mam mieć – to jest metafora, której często używam – jeżeli ja mam mieć operację serca i mi mówi kardiochirurg, słuchaj to zajmie 8 godzin i to są te nici, którymi będziemy szyć, to ja mu nie mówię rąk nie myj, przecież nic nie dotykałeś, i nie 8 godzin, tylko 4, bo ja mam ważne spotkania, a tutaj mam szczęśliwe nici od mojej babci i użyj tych nici, a nie tych swoich. Oczywiście nie ma takiej dyskusji. Dlaczego? No bo ten lekarz bierze odpowiedzialność, on wie, że żeby operacja się powiodła i żeby to miało ręce i nogi to potrzeba ileś czasu i jakichś tam konkretnych narzędzi. Nie ma dróg na skróty. Myślę, że bardzo podobnie wygląda to po stronie deweloperskiej. No i tak, żeby nie zabrzmiało to jak narzekanie, ja myślę, że tutaj jest dużo, w sensie rozwiązanie jest dosyć proste na bazie moich doświadczeń. Po prostu trzeba rozpocząć ten dialog. Myślę, że to gdzieś z tyłu głowy mieli twórcy manifestu. Poprzez bliskość osób z biznesu i z IT możemy porozmawiać sobie o tym jak to działa od strony technicznej i wielokrotnie spotykałem się z osobami biznesowymi, które doskonale zaczynały rozumieć, dlaczego nie możemy iść na skróty, albo dlaczego jest to droga, z której będziemy musieli zawrócić i zapłacić jakiś tam dodatkowy koszt, więc myślę, że jest to do zrobienia, ale wymaga dialogu.
Kuba: Taką prostą metodą, którą często proponuję w zespołach jest wykorzystanie przejrzystości . Na przykład strona biznesowa niech zobaczy na własne oczy, na czym polega czysty kod, a na czym polega brzydki kod, nieprzejrzysty. Na czym polegają testy i co dają, jak wygląda build, jak wyglądają raporty z takich rzeczy, jak wygląda automatyzacja jakości kodu, sprawdzania tego, na czym polega code review. To są procesy, które zajmują czas członkom zespołu, w niektórych organizacjach może być presja, żeby z nich rezygnować , jak z tej metafory nie myj rąk drogi kardiochirurgu, zrób kod, ale bez testów, albo code review, przecież wierzymy Ci, że robisz to dobrze. Nagle się okazuje, że to tu, to tam, procesowo, tu jakimś naciskiem, tam jakąś zmianą, presją czasu i to się wszystko sypie. Dlatego częścią tej współpracy może być transparentne wyjaśnienie wszystkim członkom zespołu scrumowego, również tym nietechnicznym jak to w ogóle wygląda, żeby też unaocznić, na czym ten proces polega no i też wyjaśnić, dlaczego chcemy to robić, dlaczego chcemy robić refaktoryzację, dlaczego niektóre rzeczy chcemy automatyzować. Pokazać, wyjaśnić ludzkim językiem, nie technicznym, trochę z wykorzystaniem takich metafor, jakich już też kilka powiedzieliśmy do tej pory, wyjaśnić wszystkim zainteresowanym, dlaczego jest to ważne. To jest asertywne i też powiedziałbym partnerskie. Do przesady to ujmując, jedna zasada, która kiedy mnie bardzo zainspirowała, to jest taka postawa, że jakość jest nienegocjowalna. Jakość jest nieodłączną częścią pracy. Moja praca nie składa się robię byle jak, plus robię to w dobrej jakości, tylko całość zajmuje tyle czasu, bo ja to chcę zrobić dobrze i nie muszę się z tego tłumaczyć. Bardzo źle, jeżeli w jakiejś firmie, zespole projektowym jest presja na to, żeby odróżnić, wycenić z testami i bez testów. Nie ma takiej wyceny. Wycena jest całości. Pracuję i wykonuje produkt w dobrej jakości.
Jacek: Tym bardziej że to wszystko jest powiązane. Tutaj powiedziałeś trochę o testach natomiast wracając do stosowania refaktoryzacji, to jeżeli ja nie mam testów, no to nie jestem w stanie sprawdzić, czy ta refaktoryzacja czegoś nie popsuła, albo czy produkt działa nadal tak, jak powinien, więc myślę, że to jest tak, że te drobne ustępstwa to są kamyczki w lawinie, które powodują kolejne i kolejne problemy.
Kuba: Jedna jeszcze rzecz, którą dodałbym w temacie doskonałości technicznej. To jest czujność na ten temat ze strony osób nietechnicznych. Ja sam jestem przedstawicielem takiego Scrum Mastera kiedyś, czy teraz agile coacha, który nie ma tego doświadczenia, czy tego korzenia technicznego. Tutaj Jacek wspomniał i mógł się powołać i pewnie w wielu dyskusjach taki Scrum Master techniczny może powiedzieć „no, sam kiedyś byłem programistą, to jest ważne”. To jest o wiele prościej to tłumaczyć. Coś, przed czym chciałbym przestrzec to, żeby czasem nie abdykować, nie zostawić tego tematu niedogadanego jeśli jesteś akurat przedstawicielem czy przedstawicielką roli Scrum Mastera, ale nietechnicznego. Masz jakieś fajne inne doświadczenia, przydatne kompetencje, ale akurat nie masz doświadczenia technicznego. To nie jest akurat wymówka, żeby tematu technicznej doskonałości nie dotykać. Oczywiście nie pomożemy, nietechniczni Scrum Masterzy programistom robić lepsze testy czy automatyzację, ale na pewno możemy być na ten aspekt czuli i też zwracać uwagę na procesy ogólnofirmowe, czy też procesy wewnątrz zespołu, które wpływają na to, czy jakość jest zastosowana, czy jest dopilnowana, czy jest przestrzegana, czy może jednak są jakieś presje, żeby tego nie robić. Tutaj nawet jeśli się nie czujemy komfortowo z tym tematem to i tak o tym rozmawiajmy. Po pierwsze dokształćmy się, to jest do nadrobienia, żeby w ogóle mieć rozeznanie w temacie doskonałości technicznej, po drugie zwracajmy uwagę na to, rozmawiajmy z zespołem o tym, jakie rzeczy pomagają im robić dobra jakość, a jakie rzeczy im przeszkadzają, bo możliwe, że to tam są te obszary, w których trzeba podziałać. Na przykład przeciwstawić się presji managmentu, terminu, gonienia jakichś wytycznych i zaciągania długu z gigantycznymi odsetkami, których nie za bardzo potem jest komu spłacać.
Jacek: Tak. Trzeci temat, który Martin poruszył w swojej prezentacji, do którego też chcielibyśmy się odnieść, to jest temat orientacji projektowej i zestawienie tego typu orientacji z orientacją typowo produktową. Ja myślę, że generalnie obraz, który mam przed oczyma kiedy dołączam do firm, które szukają wsparcia jeżeli chodzi o usprawnianie sposobu, w jaki wytwarzane są produkty albo projekty to mimo wszystko powiedziałbym, że częściej spotykam się z takim klasycznym podejściem, czyli, że mam jakiś konkretny zespół i do tego zespołu trafiają konkretne projekty. To są projekty z różnych obszarów produktu, dotyczące różnych biznesów no i zespól często jest traktowany, jako ta maszyna, która na wejściu dostaje specyfikację projektową, magicznie, pomimo że pracujemy Scrumem pojawia się dodatkowo Project Manager no i on dba, żeby tutaj wszystkie zasoby utylizowane były w jak najbardziej efektywny sposób.
Kuba: Gdzie efektywność oznacza 100 %.
Jacek: Zajętości, tak. Zwykle to kończy się tak, że jest presja czasu, szybko, szybko no i ten biedny zespół dostaje jakiś temat, którego najczęściej w ogóle nie zna, zwykle nie do końca rozumie, jaka jest potrzeba biznesowa stojąca za tym projektem biznesowym, a co gorsza myślę, jest kompletnie oddalony od użytkownika końcowego i zwykle on się w ogóle nie pojawia. Już nie mówię, że ma się pojawić fizycznie, jako osoba na przeglądzie sprintu czy jako osoba, z którą możemy podczas Refinementu podyskutować, żeby lepiej zrozumieć potrzebę, ale jak się posłucha dyskusji, które się toczą przy takich projektach, to tam zwykle dyskusja jest na poziomie technicznym, czyli jak te klocki poukładać, żeby one działały, no i dwa, jest odniesienie do wymagań, które zostały najczęściej wytworzone poza zespołem, a zespół ma po prostu je zrealizować.
Kuba: Martin mocno ten temat eksploruje, że agile w zamierzeniu był stworzony przez programistów, dla programistów, w świecie wytwarzania oprogramowania, a dosyć szybko został podłapany przez kierowników projektów i osoby z takim mindsetem projektowym. Dużo można by drążyć wątek co jest nie tak z mindsetem projektowym. On jest powiązany m.in. z doskonałością techniczną. Projekt ma w zamierzeniu swój początek i koniec. Ma jakiś termin, robię coś, zrobiłem, wdrażam, po nas choćby potop. Myślenie produktowe o wiele bardziej skupia się na tym, że rozwijam produkt, owszem, teraz wprowadzam jakaś nową cechę, nowy kraj, nowego użytkownika, nowe elementy do tego produktu, ale ten produkt przez cały cykl życia produktu musi być, działać istnieć. Ja nie mogę dzisiaj zaciągnąć długu, skompromitować jakość tego produktu, bo owszem, skończę projekt, ale po tym projekcie stracę wszystkich klientów, bo oni przestaną korzystać z mojego rozwiązania, bo przestało być użyteczne, przestało być dobrej jakości, przestało mieć wartość dla faktycznego klienta. Tutaj myślenie produktowe jest takie o wiele bardziej długofalowe , po tym danym przedsięwzięciu, danym projekcie, danej inicjatywie będzie jeszcze kolejne i kolejne, i będziemy tak długo jak się da, starali ten produkt rozwijać i utrzymywać przy życiu, zarabiać na nim, a nie tylko dążyć do tego, żeby odhaczyć progres projektu na zielono, main story dotrzymane, tutaj brawa, podziękowania za wdrożenie, piękny mail do całej firmy, że dzięki jakiemuś kierownikowi projektu się to udało i już nie wnikamy w to, ze 100 błędów na produkcji zaraz po wdrożeniu.
Jacek: Biedne zespoły, które będą na tym obszarze produktowym robić kolejne inicjatywy, no bo tam może być naprawdę krajobraz księżycowy.
Kuba: Tak. I tą inną wadą podejścia projektowego, które warto zastąpić myśleniem produktowym to to, że projekty mają też, powiem z praktyki, nie znajdę na to dowodu naukowego, mają taką zaskakująca właściwość, że duży projekt staje się coraz większy. A bardzo duży projekt staje się jeszcze większy. Rzadko spotykamy projekt, w którym bez jakiegoś wielkiego kryzysu ktoś powie słuchajcie, zróbmy to o wiele mniejsze. Raczej jest tak, że jak już to robimy, to jeszcze to, jeszcze tamto, tu dołóżmy coś do zakresu, to wymaganie jest podobne do kolejnego, które możemy zrobić i tak się okazuje, że każdy dobry pomysł automatycznie puchnie do gigantycznych rozmiarów i to puchnie ściśle tylko na tej warstwie zakresu. To nie jest temat na poziomie rozwiązań, na poziomie rozwiązań architektonicznych tylko po prostu jak już robimy tę zakładkę, to zróbmy sąsiednią, jak zrobimy trzy, to zróbmy cały wielki kombajn. Tutaj oczywiście można utyskiwać na temat wizji biznesowej przy takich projektach, ale bardzo trudno się robi NVP w firmach, które mają podejście projektowe. Robimy ten projekt, mało tego w wielu przypadkach słyszę coś takiego: no my zrobimy ten projekt i później będziemy się musieli dopominać na nowo, czy jak rozmawiam z jakimiś liderami projektu, z jakimiś biznesowymi sponsorami, że teraz mam okienko i muszę to zrobić. Ja owszem chętnie robiłbym mniejszymi kawałkami, ale jak zrobię mały kawałek, to mi mogą zamknąć projekt i nie zrobię tego wszystkiego, co chcę zrobić. To są realne historie, z realnych firm. Tak po prostu się zazwyczaj dzieje. Tutaj myślenie produktowe mówi, zrobię tę małą cechę, mały ficzer, małą zmianę i później kolejną, po tygodniu kolejną, a nawet jak mam duży pomysł na jakąś wielką zmianę to postaram się wprowadzić tą clou sprawy, esencje to najważniejsze co chcę zmienić i będę to rozbudowywać, kraj po kraju, biznes po biznesie, zakładka po zakładce czy pole po polu. Naprawdę nie ma powodu w dzisiejszym świecie, zwłaszcza w produktach takich bardzo cyfrowych, żeby nie korzystać z tej okazji, żeby w zasadzie co chwilę aktualizować, co chwilę rozwijać. Tu świetnie agile działa, bo to będzie coś w stylu co sprint, wdrożenie, a nie po 6, 8, 10, nastu sprintach, wdrożenie, wielki bing bang, tygodniowe czy wielotygodniowe testy, bo mamy gigantyczny stres i ryzyko wdrożenia jakiegoś wielkiego projektu.
Jacek: Poruszyłeś teraz masę wątków, muszę teraz zdjąć ze swojego stosu w głowie, do którego się odnieść. Co ostatnie, powiedziałeś o tych szybkich wdrożeniach. To pięknie się łączy z tą doskonałością techniczną. Jeżeli nie mamy odpowiednio przygotowanej struktury kodu, jeżeli nie mamy ciągłej integracji i tak dalej, jeżeli nie mamy testów automatycznych to po prostu nie jesteśmy w stanie blisować szybko, to jest jakby pierwsza rzecz. Druga rzecz, która mi przyszła do głowy to no tak, robimy te projekty, mówiłeś o tym jak te wymagania puchną, tego jest coraz więcej. To stoi absolutnie w sprzeczności z tym, co znajdziemy w pryncypiach Manifestu Agile, gdzie jest wyraźna mowa, o tym, że sztuką jest maksymalizowanie pracy niewykonanej, czyli powinniśmy myśleć o tym jak spełnić potrzebę klienta, użytkownika w najprostszy możliwy sposób i znów używając podejścia iteracyjnego doprowadzić to do stanu, kiedy uważamy, że dalej nie ma sensu inwestować albo po prostu nie ma takiej potrzeby. Projekty w całej tej otoczce, o której powiedziałeś z natury rzeczy chcą puchnąć i chcą mieć wszystko, no bo tak jak mówiłeś, mam okienko, mogę tylko teraz. Moim zdaniem koniec końców jest to ze szkodą i dla firmy i dla użytkownika końcowego.
Kuba: Zwłaszcza jeśli jeszcze jedna jest cecha, nazwę to wrodzona, w praktyce przy projektach, to jeśli projekt ma jakąś z góry założoną listę wymagań czy zakres to bardzo trudno się od niej odchodzi. Ktoś, gdzieś kiedyś zaakceptował ten projekt, jakiś sponsor, jacyś interesariusze zgodzili się, że chcemy zrealizować pewną konkretną rzecz, wizję, pewnie konkretny zakres i też wielokrotnie właściciele produktów, z którymi pracuję, którzy pracują w projektach, mają duży kłopot zarówno wewnętrznie w sobie samych jak i na zewnątrz w firmie, żeby przeprowadzić jakąś zmianę, co znowu jest bardzo niefajne w zderzeniu z pryncypią „Bądźmy otwarci i gotowi na zmianę, bądźmy gotowi na tę zmianę nawet późno w projekcie”. No ale jeśli ktoś, gdzieś, kiedyś obiecał komuś jakiś zakres, zadeklarował się, że coś zrealizuje później bardzo trudno tę zmianę zrealizować. To jest takie coś, że świadomie albo o wiele częściej nieświadomie jesteśmy ślepi na te wszystkie okazje biznesowe, które się pojawiają, na okazje, żeby zrobić produkt jeszcze lepszy, niż pierwotnie sobie wyobrażaliśmy. Tutaj pracujemy iteracyjnie, przyrostowo i realizujemy z góry założony zakres. To jest jakby bez sensu. Jeśli mamy zrealizować z góry założony zakres to prawdopodobnie wydajniej, optymalniej i efektywniej będzie po prostu to realizować i się nie spinać na to, żeby co iterację był przyrost, bo i tak nie korzystamy z tej okazji. Nie wdrożymy wcześniej, nie zmienimy kierunku, nie wymyślimy jakiegoś nowego rozwiązania czy nawet to jest to, co powiedziałeś: nie szukamy okazji do tego, żeby się skonfrontować nasze założenia z tym, czego chce faktycznie użytkownik.
Jacek: Z tego mogą być tylko kłopoty. Myślę, że nikt tego nie chce, bo to wydłuży czas projektu. Myślę, że to jest dobry moment, żeby zakończyć. Z jednej strony kończy się nam już tlen w samochodzie, w którym nagrywamy, z drugiej strony dzisiaj zrobiliśmy trochę inny odcinek niż dwa poprzednie, czyli dotknęliśmy trzech różnych tematów, korzystając z okazji tego, że Martin Fawler przygotował bardzo fajną prezentację. Jeżeli chciałbyś, żebyśmy pogłębili któryś z tych tematów, ponieważ wydaje Ci się interesujący, napisz do nas na nasz adres mailowy kontakt@porzadnyagile.pl czy daj nam znać przez naszą stronę www.porzadyagile.pl bądź przez serwisy społecznościowe, których adresy można znaleźć pod wpisem tego odcinka.
Kuba: W tym odcinku skorzystaliśmy z okazji do tego, żeby wypowiedzieć swoje zdanie na temat prezentacji „The State of Agile Software in 2018″. Powiedzieliśmy co sądzimy na temat Agile industrial complex i co też każdy z nas, również Ty może zrobić z tym, żeby nie wpadać w tę pułapkę, poeksplorowaliśmy wątek technicznej doskonałości i jaki ma wpływ na zwinność i też co mogą zrobić członkowie zespołu, co może zrobić Scrum Master, co może zrobić Scrum Master nietechniczny, żeby ta techniczną doskonałość uzyskać i nawiązaliśmy trochę o tym, jakie są pułapki, jakie są zagrożenia myślenia i realizowania prac w sposób projektowy, zamiast pracy w sposób produktowy, który jest o wiele bardziej kompatybilny z podejściem zwinnym.
Cześć – ciekawy podcast i zgadzam się z Waszymi komentarzami zarówno odnośnie wystąpienia Martina jak i samego Agile w dobie obecnej.
Swojego czasu podzieliłem się też swoimi przemyśleniami po wysłuchaniu tego wykładu na LI:
https://www.linkedin.com/pulse/quo-vadis-agile-micha%C5%82-bohuszewicz/
Dzięki Michał za podzielenie się tym. Do usłyszenia!