Jak wprowadzić Agile i nie zwariować?

W ramach cyklicznych spotkań Agile Warsaw, które mamy przyjemność gościć w naszym biurze, we wrześniu odwiedził nas Jurgen De Smet – światowej klasy trener LeSS, ewangelista idei Lean Startup oraz Design Thinking. Jurgen przyjechał na zaproszenie firmy ProCognita, dzięki której mieliśmy możliwość przeprowadzenia z nim krótkiego wywiadu. Zapraszamy do lektury.

Jurgen De Smet zajmuje się wspieraniem liderów międzynarodowych organizacji w osiąganiu wysokiej produktywności. Jego zaangażowanie w kształtowanie struktury i kultury organizacyjnej, pozwala zminimalizować liczbę zależności, które wymagają koordynacji przez kadrę zarządzają. Transparentność oraz dostęp do wysokiej jakości danych umożliwia podejmowanie trafnych decyzji. W rezultacie system staje się szczuplejszy, bardziej skoncentrowany na kliencie i gotowy, z każdą kolejną falą zmian, do budowania jeszcze większych i bardziej skomplikowanych produktów.

Jurgen specjalizuje się w szczupłym (z ang. Lean) oraz zwinnym (z ang. Agile) zarządzaniu produktami, jest międzynarodowym szkoleniowcem LeSS, ewangelistą idei Lean Startup oraz Design Thinking.
 

Artur Kożuch, Deloitte: Podczas spotkania organizowanego w ramach Agile Warsaw opowiadałeś o podstawach Large-Scale Scrum (LeSS). Obserwujemy uważnie jak organizacje w Polsce skalują pracę zespołów deweloperskich i muszę przyznać, że `LeSS nie jest najbardziej popularnym frameworkiem wśród naszych klientów. Czy mógłbyś wyjaśnić, dlaczego uważasz, że organizacje powinny poświęcać więcej uwagi Large-Scale Scrum? Modny i coraz bardziej popularny "model Spotify" stanowi obecnie inspirację dla wielu przedsiębiorstw podczas budowania własnej struktury organizacyjnej. Czy widzisz jakieś przewagi LeSS nad tym modelem? Czy mógłbyś je wyjaśnić?

Jurgen De Smet: LeSS nie jest rozwiązaniem łatwym i wymaga od organizacji wdrażania gruntownych zmian, usuwania wszelkiego rodzaju zawiłości występujących pomiędzy rolami, niepotrzebnego przekazywania zadań (z ang. handovers), źle skonstruowanych mechanizmów decyzyjnych itd. Wiele organizacji nie jest gotowych na tego typu zmiany i poszukuje ram, które pozwoliłyby im na utrzymanie obecnych struktur organizacyjnych przeprowadzając jedynie powierzchowną zmianę. Tworzenie iteracyjnych procesów wewnątrz poszczególnych działów przychodzi z łatwością ale zmiana strukturalna przyczyniająca się do osiągnięcia pełnej zwinności (z ang. enterprise agility) jest prawdziwym wyzwaniem dla przedsiębiorstw. Organizacje, które są zainteresowane Large-Scale Scrum zazwyczaj mają odpowiednie nastawienie do zmian a ich transformacja już się rozpoczęła i najprawdopodobniej nigdy się nie zakończy.

Spotify to konkretna organizacja i kopiowanie jej kultury do innej firmy, najprawdopodobniej nie zadziała dobrze. Zastanawiam się czy w ogóle istnieje sytuacja, w której przewagę konkurencyjną może stanowić kopiowanie. LeSS nie jest skupiony na konfigurowaniu struktur organizacyjnych i procesów, ma za to wiele wspólnego ze Scrum – to wiarygodne lustro dla każdej organizacji. Large-Scale Scrum Framework może pokazać dużej organizacji co nie działa, tak, aby wszystkie podmioty działające w ekosystemie, mogły stale poszukiwać lepszych sposobów na wywieranie wpływu oraz dostarczanie wartości dla swoich klientów. Pierwsze zdanie w manifeście Agile mówi: „Odkrywamy lepsze sposoby wytwarzania oprogramowania poprzez praktykę i pomagamy społeczności w podążaniu tą samą drogą”. Jeżeli chcesz dowiedzieć się więcej, to zachęcam do wzięcia udziału w 3-dniowym kursie LeSS Practicioner.

AK: Twój wykład był skoncentrowany na wyjaśnieniu "jak organizacje zaczynają wariować". Niewątpliwie, każda firma z biegiem czasu rozszerza swoją strukturę i sytuacja, kiedy powołujemy nowe organy takie jak QA (Quality Assurance), PMO (Project Management Office), zespoły obsługi klienta, czy zespoły integracyjne, wydaje się nieunikniona. Czy możesz nam powiedzieć, jak uniknąć sytuacji, gdy nasza organizacja staje się „zwariowana"? Czy możliwe jest utrzymanie prawdziwej zwinności na każdym etapie kształtowania struktury organizacyjnej?

Jurgen De Smet: Myślę, że łatwo jest wypracować rozwiązanie tego problemu, dużo trudniej jest wdrożyć je w życie. Wydaje się, że my - ludzie - mamy wiele wad, a jedną z nich jest przedwczesne wyciąganie wniosków i wybieranie najłatwiejszy wyjść z sytuacji. W przypadku każdego poważnego problemu występującego wewnątrz organizacji, zazwyczaj najłatwiejszym rozwiązaniem jest utworzenie dodatkowej roli, nowego procesu, nadprogramowej bramki itd., aby uniknąć ponownego pojawienia się tego problemu w przyszłości. Jednak, musimy wziąć pod uwagę, że w ten sposób odbieramy odpowiedzialność zespołom i możemy zastać sytuację, kiedy pracujemy z samymi „zombie”. Jak więc możemy tego uniknąć? Wystarczy dać zespołom odpowiedzialność za rozwiązywanie problemów, dać im czas na zbadanie przyczyn źródłowych i dodać narzędzia do przeprowadzania pomiarów zapobiegawczych.

Wiesz, posiadam niewielką nadwagę i oddanie tego problemu mojej żonie nie rozwiąże problemu, ponieważ to ja muszę wziąć za siebie odpowiedzialność. Śledzę swoją wagę częściej (metryka opóźniająca), częściej ćwiczę i śledzę postępy, używając aplikacji (metryka wiodąca), śledzę również kaloryczność wszystkich posiłków, które spożywam (metryka wiodąca). Opłaciło się, powoli tracę na wadze. Co by się stało, gdyby moja żona śledziła wszystkie te informacje i ciągle mówiła mi, żebym więcej ćwiczył, jadł mniej, że na dzisiaj już przekroczyłem swoje zapotrzebowanie kaloryczne? Czy uważasz, że byłoby to korzystne dla naszych relacji?

Przekazanie odpowiedzialności zespołom bez powoływania nowych struktur oraz procesów, jest odpowiedzią na Twoje pytanie. Jeżeli pojawia się problem z niewystarczającą wydajnością, zawsze najkorzystniejszym rozwiązaniem jest utworzenie większej ilości zespołów. Istnieją ramy postępowania, które pozwalają na zachowanie prostoty podczas prac z kilkoma zespołami, setkami zespołów a nawet ich tysiącami (LeSS).

AK: Czy widzisz jakąś różnicę w postrzeganiu Agile jako filozofii w Polsce i innych krajach, które odwiedzasz? Czy uważasz, że Agile jest teraz traktowany jak tymczasowa moda czy raczej jako powinność dla każdej organizacji, która wytwarza oprogramowanie? Czy myślisz, że zarządzanie projektami w podejściu „dowódź i kontroluj” jest skazane na zagładę?

Jurgen De Smet: Nie mam wystarczającego doświadczenia z zarządzaniem zwinnym w Polsce, aby obiektywnie ocenić różnice pomiędzy innymi krajami. Mam za sobą dopiero pierwsze szkolenie Certified LeSS Practicioner w Polsce i uważam, że to za mało by wyciągnąć wiążące wnioski.  Aby zachować obiektywizm musiałbym zanurzyć się w oceanie organizacyjnych problemów i spróbować je rozwiązać tutaj, na miejscu, żeby zrozumieć prawdziwe różnice.

Jeżeli chodzi o Agile w skali globalnej, będzie to (jeśli jeszcze nie jest), standard dla każdej organizacji. Wątpię, czy wszystkie firmy uzyskają to, czego szukają: zwinność organizacyjną, lub super-elastyczność w dostosowywaniu się do potrzeb rynku i zmieniającego się otoczenia technologicznego. Implikacje wynikające z transformacji Agile nie są takie same w każdej organizacji. Wraz z rosnącą popularnością, złymi praktykami oraz brakiem zrozumienia, Agile zaczyna tracić na swojej wartości. Dlatego możemy się spodziewać, że w przyszłości pojawi się nowe podejście. W świecie zwinnym jest wiele rzeczy, które wynikają z zasad, które istnieją od kilkudziesięciu lat wcześniej, niż symboliczny manifest. Dlatego promuję podejście, by nie rozpraszać się przesadnie na praktyki i ramy, ale trzymać się zasad. Wtedy można mieć pewność, że organizacja będzie funkcjonowała efektywnie jeszcze przez dekady.

AK: Czy to prawda, że podczas transformacji ze starej struktury, do zorientowanych na produkt, samoorganizujących się i interdyscyplinarnych zespołów zwinnych, głównym hamulcem dla przeprowadzanych zmian są menedżerowie średniego szczebla? Jaki z Twojej perspektywy, jest najważniejszy hamulec działań transformacyjnych?

Jurgen De Smet: Rozszerzyłbym pojęcie menedżerów średniego szczebla o role, które również posiadają władzę wewnątrz organizacji, tzw. stanowiska specjalistyczne. Wydaje się, że organizacje optymalizowane są hipotetycznie, aby utrzymać te role na siłę w swoich strukturach. Wynikiem tego są struktury, które używają nowych nazw dla ról, dla takich samych zestawów obowiązków i zachowań. Pozwól, że podam Ci przykład, z którym pewnie już miałeś do czynienia. Wchodzisz jako konsultant do organizacji i poznajesz człowieka, który jest obsadzony w roli właściciela produktu (z ang. Product Owner), którego głównym zadaniem jest napisanie wymagań, ale już nie w dokumencie wymagań, tylko w rejestrze produktu (z ang. Product Backlog). Kiedyś taka osoba w organizacji nazywała się analitykiem biznesowym i mechanizm jej postępowania jest dokładnie taki sam. Jedyne co się zmieniło to nazwa obejmowanego stanowiska. Bardzo podobny przykład stanowią mistrzowie młyna (z ang. Scrum Master), którzy podczas planowania sprintu (z ang. Sprint Planning) przepytują kolejnych członków zespołu, czy ich czas został już w pełni zutylizowany. Czy to brzmi znajomo?

20 lat temu, kiedy zacząłem pracować, w Scrum nie było powszechnym zjawiskiem, że osoby posiadające umiejętności związane z testowaniem oprogramowania, były członkami zespołów deweloperskich – inżynierowie ds. testów zajmowali specjalne stanowiska. Dziś jest to powszechne, ale słyszę to samo, co w przypadku specjalistów ds. bezpieczeństwa, UX, UI, analizy danych, czy projektowania... Tak, to oczywiste, że potrzebujemy specjalizacji, ale nie w oddzielnym departamencie. Wynikiem separowania kompetencji jest to, że aby uzyskać wartość potrzebujemy znacznie częściej przekazywać wszystkie informacje (z ang. handovers) Bardzo polecam film o tworzeniu autonomicznych samochodów, aby móc sobie wyobrazić o ilu specjalizacjach rozmawiamy w tym przypadku. Organizacja zdecydowała się, aby zamiast tworzyć poszczególne działy, zintegrować prace w ramach struktur poszczególnych kros-funkcyjnych zespołów.

Jakkolwiek, nadal uważam, że nie jest to największa bariera w transformacji Agile. Najważniejszy hamulec zmian to kontraktowy sposób myślenia w organizacjach, który jest mocno powiązany z raportowaniem -  CAPEX (wydatki inwestycyjne)  i OPEX (wydatki operacyjne).

AK: Ostatnie pytanie, już zupełnie poza tematyką Agile. Czy możesz nakreślić najgorętsze tematy dotyczące rozwijania oprogramowania oraz zarządzania projektami IT, na które  powinniśmy zwrócić uwagę w nadchodzących latach? Zarządzanie 3.0, Beyond Budgeting, DevOps? Czy mógłbyś krótko przedstawić, jak wg. Ciebie wygląda przyszłość branży?

Jurgen De Smet: Osobiście rekomendowałbym przyjrzeć się bliżej trendom technologicznym i aplikacjom nowoczesnych rozwiązań, niż jeszcze jednej praktyce zarządzania lub metodyce. Dlaczego?

Kiedy zadaję pytanie organizacjom, ile czasu zajęłoby im zrealizowanie pomysłu, który wpłynąłby na co najmniej jedną grupę użytkowników ich produktu, jeszcze nigdy nie otrzymałem informacji, że w ciągu dwóch tygodniu lub jednego sprintu. Pytając, ile osób liczy organizacja zazwyczaj dowiaduję się, że setki lub tysiące specjalistów. Wyobraźmy sobie, że mamy osiem zespołów, po dziesięć osób, pracujących nad produktami i nie możemy dostarczyć nawet jednego imponującego i rewolucyjnego pomysłu w ciągu trwania sprintu. Przecież to jest równoznaczne ze stwierdzeniem, że dysponujemy rzeszą ośmiuset pracowników, aby zrobić tylko jedną imponującą funkcjonalność, ale… to jest właśnie problem współczesnych organizacji. To nie jest prawdziwa zwinność.

Kiedy przejdziemy do sytuacji, w której osiem zespołów chce pracować nad jednym celem, sprawność technologiczna (z ang. technical excellence) staje się barierą. Organizacje, które korzystają z narzędzi ciągłej integracji (z ang. continuous integration), oraz ciągłego dostarczania (z ang. continuous delivery), nie rozumieją istoty ich działania. Wszystkie opóźnienia wynikające z ciągłej integracji, będą utrudniać zespołom współpracę nad jednym celem, oraz powodować zarządzanie skupione na człowieku. Poruszyłem ten temat szerzej w artykule „Using the Sprint Goal, Technical Excellence & Delivering Value”. Uwielbiam praktyki i pomysły z zakresu zarządzania 3.0, uwielbiam Beyond Budgeting oraz podejście DevOps, ale podobnie jak w przypadku Scrum, w znakomitej większości przypadków są one stosowane z punktu widzenia praktyki lub procesu i nie rozumiem, do czego tak naprawdę są przeznaczone. 

Dla mnie przyszłość naszej branży polega na umożliwieniu zdalnym zespołom współpracy. Nie tylko z innymi ludźmi, ale także z maszynami. Przez „maszyny” mam na myśli określenie jak współpracować z sztuczną inteligencją (AI) i głębokimi algorytmami uczenia się maszynowego. Musimy nauczyć się jak współpracować z systemami, które są inteligentniejsze i mniej omylne niż my sami.