Jak sprawić, by metodyka Agile działała dzięki metagility (z Davidem Bishopem z Agile Worx)

Przeczytaj transkrypcję:

Wypróbowujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie jest poprawny w 100% przypadków.

Ben Aston: Załóżmy, że pracowałeś zgodnie z modelem kaskadowym, ale to nie zadziałało, a następnie spróbowałeś Agile — i to również nie działało zbyt dobrze.

Teraz więc łączysz różne podejścia. Masz porcję Agile, porcję modelu kaskadowego i próbujesz znaleźć kilka posypek, które możesz dodać na wierzch. Posłuchaj dzisiejszego podcastu o metagility. Być może dowiesz się czegoś o tym, jak podręcznik Agile może pomóc połączyć najlepsze elementy obu światów.

Dziękuję za dołączenie. Nazywam się Ben Aston i jestem założycielem The Digital Project Manager. Witajcie w podcaście DPM. Naszą misją jest pomaganie kierownikom projektów w osiąganiu sukcesu oraz osobom zarządzającym projektami w dostarczaniu lepszych rezultatów. Chcemy pomóc Ci przenieść zarządzanie projektami na wyższy poziom. Odwiedź thedigitalprojectmanager.com, aby dowiedzieć się więcej o szkoleniach i zasobach dostępnych w ramach członkostwa. Ten podcast powstał dzięki firmie Clarizen, liderowi w dziedzinie oprogramowania do zarządzania projektami i portfelami projektów dla przedsiębiorstw. Odwiedź Clarizen.com, aby dowiedzieć się więcej.

Dziś dołącza do mnie David Bishop. Dr David Bishop jest technologiem, konsultantem, przedsiębiorcą badawczym i instruktorem z ponad 25-letnim doświadczeniem w sektorach telekomunikacyjnym, transportowym, publicznym i użyteczności publicznej. Jest dyrektorem generalnym i założycielem Agile Worx, LLC. Możecie odwiedzić stronę Agile-worx.com. To firma oferująca narzędzia programowe do zarządzania programami i projektami, szkolenia oraz usługi konsultingowe. David jest także autorem książki Metagility: Managing Agile Development for Competitive Advantage. Davidzie, bardzo dziękuję, że jesteś dziś z nami.

David Bishop: Dziękuję za zaproszenie.

Ben Aston: Chciałbym zagłębić się w ideę budowania ram działania od podstaw. Czy możesz opowiedzieć nam trochę o swoim doświadczeniu i o tym, jak doszedłeś do wniosku, że świat potrzebuje nowych ram? Jakie doświadczenia doprowadziły Cię do tego punktu?

David Bishop: Od około dwudziestu pięciu lat zajmuję się rozwojem technologii, głównie jako architekt systemów i inżynier systemowy, tworząc rozwiązania z wykorzystaniem nowych technologii. Pracowałem w branży IT, a także w lotnictwie, telekomunikacji komórkowej i innych powiązanych obszarach. Jak wspomniałeś, około dziesięciu lat temu rozpocząłem pracę w firmie, która intensywnie rozwijała przemysłowy internet rzeczy. Jedną z rzeczy, które firma bardzo starała się zrobić, było wdrożenie metodyk Agile.

Ben Aston: Rozumiem.

David Bishop: Powodem były oczekiwania klientów. Firma działała w stosunkowo nowym obszarze technologicznym i próbowała zintegrować się z nową branżą. Na rynku było wielu konkurentów rozwijających nową technologię inteligentnych sieci wraz z różnymi rozwiązaniami komunikacji radiowej.

Firma wielokrotnie próbowała wdrożyć Agile, ponieważ szybkie wprowadzanie produktów na rynek było dla niej kluczowe. Podejmowała wiele prób, angażowała wysoko opłacanych konsultantów, ale za każdym razem ponosiła porażkę. Byłem częścią tego procesu: pomagałem organizacji rozwijać produkty, a także wdrażać Agile. Zacząłem się zastanawiać, czy nie istnieje inny sposób działania.

Dlaczego tylu bardzo inteligentnych konsultantów, których angażowaliśmy, miało z tym tak duże problemy? Zdałem sobie sprawę, że Agile odniósł ogromny sukces i z pewnością jest świetną ideą, ale ma również pewne ograniczenia. Dotyczą one między innymi zespołów rozproszonych, dużych zespołów, bardzo złożonych środowisk rozwojowych oraz skomplikowanych produktów. Wszystko to może stanowić ogromne wyzwanie dla osób próbujących wdrożyć metodykę Agile w jej najbardziej klasycznej formie.

Ben Aston: Zdecydowanie. Opowiedz więc trochę o swoim doświadczeniu w tych projektach. Ciekawi mnie codzienna, praktyczna strona tego zagadnienia. Rozumiem ogólny obraz wyzwań związanych z wdrożeniem Agile, ale jak wyglądało to w praktyce? Jakie problemy pojawiały się na co dzień? Jakie sygnały ostrzegawcze wskazywały, że coś nie działa właściwie?

David Bishop: W niektórych zespołach występował ogromny opór. Nie chodziło o lekką niechęć, lecz o bardzo silny sprzeciw i skargi, że proces po prostu nie działa i nie może działać. Wynikało to z faktu, że pracowaliśmy w środowisku systemów wbudowanych. Produkty internetu rzeczy nie były wyłącznie oprogramowaniem — były urządzeniami. Urządzenia zwykle składają się z systemów wbudowanych, w których sprzęt, oprogramowanie układowe i oprogramowanie są rozwijane przez różne ścieżki, zespoły, działy, a czasem nawet firmy.

W pewnym momencie wszystkie trzy elementy muszą jednak zostać przetestowane i wydane jako jeden spójny produkt. Właśnie tym zajmowała się ta firma. Ten kontekst jest dziś bardzo interesujący, ponieważ to właśnie tam obecnie zachodzi wiele innowacji. Kiedy po raz pierwszy opublikowano manifest Agile, koncentrował się on na oprogramowaniu. Dziś nie chodzi już tylko o oprogramowanie.

Chodzi o urządzenia, inteligentne urządzenia, inteligentne liczniki, inteligentne samochody i telefony komórkowe. Właściwie wszystko jest dziś urządzeniem opartym na systemie wbudowanym. Firmy tworzące takie produkty mają największe trudności z osiąganiem zwinności właśnie ze względu na ich złożoność. Na co dzień współpracowaliśmy z konsultantami, którzy mówili: „Wasze zespoły programistyczne pracują w dwutygodniowych sprintach i organizują codzienne spotkania, ale nie potrafimy skłonić zespołów sprzętowych do pracy w ten sam sposób. Nie widzą takiej potrzeby”.

Ben Aston: Rozumiem.

David Bishop: Zespoły zajmujące się oprogramowaniem układowym miały ten sam problem. Mówiły: „To nie działa dobrze i nie ma dla nas sensu”. I rzeczywiście tak było, ponieważ zespoły programistyczne pracowały znacznie szybciej. Mogły rozwijać rozwiązania iteracyjnie, ale nie sprawdzało się to w przypadku zespołów sprzętowych. Ich produkty miały cykl wydawniczy trwający od 12 do 18 miesięcy.

Włączenie układu scalonego do sprzętu i jego dokładne przetestowanie wymagały dużo czasu. Ponadto większość organizacji rozwijających systemy wbudowane działa w branżach, w których występują regulacje, wymogi zgodności, nadzór państwowy i podobne ograniczenia.

Pomyśl o inteligentnych licznikach w przedsiębiorstwach energetycznych, inteligentnych samochodach albo systemach awioniki w samolocie. Możesz sobie wyobrazić, że stawka jest tam znacznie wyższa ze względu na potencjalną utratę życia lub katastrofalne awarie. Takie systemy muszą spełniać znacznie wyższe wymagania dotyczące jakości, wydajności i niezawodności niż typowa aplikacja internetowa czy sklep internetowy.

Ben Aston: To ma sens.

David Bishop: Większość branż, które najwcześniej i najszybciej przyjęły metodyki Agile, zajmowała się właśnie prostszymi produktami programistycznymi.

Ben Aston: Jeśli chcecie dowiedzieć się więcej o początkach metagility, możecie przeczytać artykuł na stronie thedigitalprojectmanager.com. Opisuje on ewolucję tej koncepcji i historię powstawania książki. Zamiast zagłębiać się w tę historię, chciałbym porozmawiać o samych ramach działania i sprawdzić, jakie elementy możemy zastosować w naszych projektach.

Myślę, że jest to bardzo istotne, ponieważ wielu z nas próbowało stosować elementy modelu kaskadowego. Działamy sekwencyjnie, bo wydaje się to najbardziej rozsądne ze względu na interesariuszy i sposób organizacji współpracy. Jednocześnie próbujemy wykorzystywać elementy Agile: pracujemy zespołowo i iteracyjnie. Wybieramy różne fragmenty podejścia i przyjmujemy jego filozofię: iterujmy, często dostarczajmy wartość, budujmy, testujmy i uczmy się.

W praktyce jednak musimy pracować sekwencyjnie. Chciałbym więc porozmawiać o metagility i o tym, jak możemy stosować ją w projektach. Metodyki Agile są popularne i powszechnie uznawane za najlepszy sposób zarządzania tworzeniem oprogramowania, ale znaczenie pojęcia „metodyka Agile” pozostaje otwarte na interpretację.

Jak już mówiliśmy, stanowi to prawdziwe wyzwanie dla wielu firm. Podejście hybrydowe, choć nie zawsze przedstawiane jako najlepsze rozwiązanie, jest w praktyce domyślnym sposobem działania wielu osób, które próbują połączyć różne ramy i sposoby pracy z ograniczeniami organizacji.

Sprzęt może wymagać dłuższego cyklu tworzenia niż oprogramowanie, a warstwa pośrednia może zajmować miejsce gdzieś pomiędzy nimi. To samo wyzwanie pojawia się czasem w tworzeniu stron internetowych: doświadczenie użytkownika i projektowanie mogą przebiegać szybko, ale programowanie zajmuje znacznie więcej czasu.

Chciałbym porozmawiać o problemie, który opisujesz w książce: o wydajności i ograniczeniach metodyk Agile. Porozmawiajmy na wysokim poziomie o SAFe, a na poziomie taktycznym o Scrumie. Jakie ograniczenia dostrzegasz?

David Bishop: Jeśli mówimy o ramach takich jak Scrum, Kanban, DSDM, LeSS czy Disciplined Agile, to każda z nich próbuje rozwiązać problem z innej perspektywy. Wiele osób niewłaściwie rozumie powód wdrażania metodyk Agile. Obecnie często mówi się, że Agile sprawia, iż zespoły lepiej współpracują, przyczynia się do lepszego przywództwa albo zwiększa efektywność. To wszystko jest wartościowe.

Jednak prawdziwym celem Agile jest konkurencyjność — zajęcie pierwszego miejsca na rynku. Manifest Agile był inspirowany produkcją odchudzoną i systemem produkcyjnym Toyoty. Toyota przeszła drogę od producenta przeciętnych samochodów do jednego z czołowych producentów samochodów na świecie.

Cała idea zwinności polega na powieleniu tego rodzaju sukcesu i zdobyciu pozycji lidera rynku. Wiele ram działania o tym zapomniało. SAFe koncentruje się na poziomie przedsiębiorstwa, czyli na bardzo szerokiej perspektywie, próbując wprowadzić zwinność do każdego obszaru firmy — działu HR, działu prawnego i innych jednostek.

Scrum skupia się na poziomie zespołu i jest zestawem rytuałów pomagających zarządzać zespołami. Kanban koncentruje się na przepływie pracy i procesie. Metagility natomiast skupia się na silniku rozwoju produktu: zarządzaniu produktem, zarządzaniu projektem, zespołach programistycznych i testowych, rozwijaniu oraz interpretowaniu wymagań, testowaniu produktu, wprowadzaniu go na rynek i współpracy z klientem.

Jeśli chcesz wygrać wyścig, musisz skoncentrować się na tym, co rzeczywiście decyduje o zwycięstwie. Jeśli budujesz samochód do wyścigu na ćwierć mili, skupiasz się na silniku, skrzyni biegów i układzie napędowym, a nie na elektrycznych szybach czy klimatyzacji.

Właśnie to robi metagility. Na podstawie badań wyodrębniliśmy grupę studiów przypadków, w których organizacje osiągnęły coś, co nazywam superzwinnością. Wykorzystały zwinność, aby stać się liderami rynku. Metagility zbiera to, co te firmy zrobiły właściwie, i próbuje przekształcić to w podejście, które inne organizacje mogą powielić.

Ben Aston: Opisujesz metagility jako kompleksowe podejście do zarządzania nowym i bardzo skutecznym rodzajem tożsamości. Czym właściwie jest metagility? Ramami dostarczania, metodyką, a może podręcznikiem działania?

David Bishop: Opisałbym ją po prostu jako ramy działania. Prowadzą one przez proces podejmowania decyzji dotyczących rodzaju transformacji Agile, który chcesz przeprowadzić. Książka zaczyna się od nauki innego sposobu myślenia — opartego na badaniach i metodach naukowych przy podejmowaniu decyzji biznesowych.

Znajduje się tam także część poświęcona temu, jak manifest Agile zmienił się pod wpływem wyników badań. W części dotyczącej transformacji Agile omawiamy między innymi to, czy należy wdrożyć czyste Agile, podejście hybrydowe, czy pozostać przy modelu kaskadowym. W niektórych przypadkach model kaskadowy może być właściwym wyborem.

Istnieje wiele recenzowanych badań biznesowych, które pomagają odpowiedzieć na to pytanie. Decyzja dotycząca rodzaju wdrożenia Agile powinna zależeć od złożoności zależności w produkcie i organizacji oraz od wielkości zespołów. W przypadku złożonych produktów, dużych zespołów rozproszonych i licznych zależności podejście czysto Agile zwykle się nie sprawdza. Potrzebne jest coś innego — podejście hybrydowe. Jeśli zostanie zastosowane celowo, może przynieść znakomite rezultaty.

Ben Aston: Czy możesz opisać, jak te ramy działają i jakie są ich elementy?

David Bishop: Pierwszym krokiem jest podjęcie decyzji, jaki rodzaj transformacji należy przeprowadzić. Następnie metagility określa, jak poszczególne zespoły powinny przyjąć elementy Agile lub modelu kaskadowego.

Zespoły programistyczne mogą pracować w dwutygodniowych sprintach i organizować codzienne spotkania, podczas gdy zespoły sprzętowe mogą pracować w cyklach trwających od 12 do 18 miesięcy. Mogą działać bardziej kaskadowo, wykorzystując techniki takie jak szybkie prototypowanie, aby nadążać za pozostałymi zespołami.

Najważniejsze jest utrzymanie przepływu w całym procesie. Bramy etapów modelu kaskadowego mogą działać jako mechanizm kontroli i równowagi, pomagając zsynchronizować ścieżki poruszające się z różną prędkością.

Metagility definiuje również metryki oraz rodzaje interakcji, które należy stosować. Na podstawie najbardziej udanych studiów przypadków wyróżniamy sześć jasno określonych kategorii interakcji i opisujemy, jak je wdrażać oraz nimi zarządzać. Dzięki temu metagility staje się szczegółowym podręcznikiem prowadzenia hybrydowej transformacji Agile.

Ben Aston: Jak ustalić właściwe połączenie różnych cech Agile? Ludzie często reagują negatywnie na zmiany. Jak określić właściwy poziom zwinności i zdecydować, czy obecny stan jest akceptowalny, czy też potrzebna jest ewolucja albo rewolucja?

David Bishop: Najlepszą odpowiedź można uzyskać dzięki metodologii naukowej i badaniom angażującym. Ludzie często polegają na intuicji, najlepszych praktykach, wywiadach i próbach osiągnięcia konsensusu. Nie ma w tym nic całkowicie niewłaściwego, ale transformacja Agile, DevOps czy transformacja cyfrowa wymaga silniejszego podejścia.

Środowiska informatyczne są bardzo zależne od kontekstu. Różnią się znacznie między firmami, więc rozwiązanie skuteczne w jednym miejscu nie zawsze sprawdzi się gdzie indziej. Dzięki interpretacyjnym studiom przypadków, etnografiom i innym metodom badawczym można określić, które elementy da się uogólnić i zastosować w kolejnej organizacji.

Ben Aston: To nie są więc ramy uniwersalne, lecz konfigurowalne. Jak ocenić, czy wdrożenie rzeczywiście jest zgodne z metagility i czy odniosło sukces?

David Bishop: Metagility obejmuje również teorię wirowości Agile. Odpowiada ona na pytanie, jak bardzo zwinna jest organizacja. Przez długi czas nie istniał dobry sposób pomiaru zwinności. Teoria wirowości Agile pozwala mierzyć ten poziom oraz sprawdzać, czy działania przynoszą poprawę.

To złożona koncepcja, którą szczegółowo opisuję w książce. Powstała na podstawie badań i wypełnia istotną lukę w tej dziedzinie.

Ben Aston: Jaki wpływ widziałeś w organizacjach, które wdrożyły te ramy?

David Bishop: Wiele naszych studiów przypadków dotyczyło rynku systemów wbudowanych — jednego z najciekawszych, najbardziej dynamicznych i najtrudniejszych rynków. Firmy, które przyjęły koncepcje metagility, w większości przypadków stały się liderami rynku albo znalazły się bardzo blisko tej pozycji.

Przekłada się to na udział w rynku i większą liczbę urządzeń funkcjonujących w terenie. Kluczem do długowieczności jest zdobycie krytycznego udziału w rynku, zanim zrobią to konkurenci. Oznacza to szybkie przyjmowanie innowacyjnych technologii i wprowadzanie ich na rynek przed innymi.

Najbardziej udane organizacje skróciły cykle pracy tak bardzo, jak było to możliwe, utrzymały oczekiwaną jakość i satysfakcję klientów, a następnie wprowadziły innowacyjne produkty na rynek, zdobywając przewagę nad konkurencją.

Ben Aston: Kiedy metagility nie działa? Jakie problemy pojawiają się podczas wdrożeń?

David Bishop: Widzę dwa główne obszary. Pierwszy to brak poparcia kadry kierowniczej. Bez zaangażowania i wsparcia kierownictwa transformacja nie zajdzie daleko. Trzeba wyjaśnić, jaki jest cel transformacji i jak wpłynie ona na wyniki finansowe.

Drugi problem to słabe zarządzanie wymaganiami. Organizacje często skupiają się na zespołach programistycznych i testowych, ale poświęcają zbyt mało uwagi analitykom biznesowym i właścicielom produktu.

W środowisku Agile nie „zbiera się” wymagań — wymagania się rozwija. To zasadnicza różnica. W modelu kaskadowym analityk stara się zdefiniować wszystkie wymagania z wyprzedzeniem, ponieważ zakres, koszt i harmonogram są dokładnie określone. W Agile wymagania są rozwijane we współpracy z klientem i mogą być udoskonalane w kolejnych iteracjach.

Jeśli analitycy zaczynają tworzyć coraz więcej wymagań bez właściwej priorytetyzacji, wydania zostają przeładowane, powstają niedostatecznie wykorzystywane funkcje, a dług techniczny wymyka się spod kontroli. W ten sposób transformacje Agile ponoszą porażkę. Każde ramy, w tym metagility, mogą zawieść, jeśli organizacja nie zmieni sposobu rozwijania wymagań.

Ben Aston: Jeśli ktoś dopiero poznaje metagility, jaki pierwszy krok może podjąć organizacja?

David Bishop: Pierwszym krokiem powinno być zbudowanie nowych relacji z klientami. Manifest Agile mówi o współpracy z klientem ponad negocjowanie umowy, ale badania pokazują, że negocjowanie umowy i współpraca z klientem są w rzeczywistości tym samym procesem.

Negocjacje zachodzą na wszystkich poziomach organizacji — między menedżerami produktu, właścicielami produktu, kierownikami projektów, zespołami programistycznymi i innymi interesariuszami. Trzeba zbudować relację opartą na współpracy.

Klient powinien uczestniczyć w testowaniu, szczególnie jeśli organizacja chce szybko wprowadzić innowacyjny produkt na rynek. Najbardziej udane firmy miały jasną wizję i podejmowały strategiczne decyzje dotyczące tego, z którymi klientami będą pracować.

Nie każdy klient jest właściwy. Niektóre firmy musiały odrzucić klientów, którzy nie chcieli współpracować i uczestniczyć w procesie. Znalezienie odpowiednich klientów oraz zbudowanie silnej relacji opartej na współpracy to prawdopodobnie pierwszy krok.

Ben Aston: To bardzo trafna rada. Często przyjmujemy wszystko, co pojawia się na wejściu, ale jeśli chcemy dostarczać klientom rzeczywistą wartość, potrzebujemy właściwego modelu współpracy. Zaufanie umożliwia współdziałanie i pozwala osiągnąć lepszy rezultat niż spory o literalne brzmienie umowy.

Dziękuję, Davidzie, za rozmowę i wyjaśnienie, czym jest metagility.

David Bishop: Dziękuję bardzo.

Ben Aston: Chciałbym wiedzieć, co o tym sądzicie. Jeśli czytaliście książkę metagility , napiszcie w komentarzach, co o niej myślicie. Jeśli jeszcze jej nie czytaliście, umieścimy link w transkrypcji. Davidzie, gdzie można dowiedzieć się więcej o Tobie i Twojej książce?

David Bishop: Można wyszukać w Google słowo „metagility” i znaleźć wiele materiałów. Można również odwiedzić stronę Agileworx.com (Agile-worx.com), aby dowiedzieć się więcej o naszej firmie. Oferujemy również kursy. Można sprawdzić najnowszy harmonogram na stronie metagility.technology i zapisać się na zajęcia. Można też skontaktować się ze mną pod adresem David@agileworx.com.

Ben Aston: Świetnie. Dziękuję, Davidzie. Jeśli chcesz dowiedzieć się więcej i rozwijać swoją karierę, dołącz do nas. W ramach członkostwa DPM odwiedź thedigitalprojectmanager.com/membership. Otrzymasz dostęp do naszego zespołu Slack, szablonów, warsztatów, sesji AMA, dyżurów, e-booków i innych materiałów. Jeśli podobało Ci się to, czego dziś słuchałeś, zasubskrybuj podcast i pozostań z nami na stronie thedigitalprojectmanager.com. Do usłyszenia następnym razem. Dziękuję za uwagę.