Jak pokazać, że agile „nie działa”? Najłatwiej jest ograniczyć całą zwinność do jednego pilotażowego procesu, zespołu lub komórki organizacyjnej. Nawet jeśli pozwolimy im na wszystko, to i tak możemy na koniec pokazać, że nic się nie zmieniło. Bo przecież nie miało prawa.
Ograniczenia procesowe
Najczęstszym oczekiwaniem związanym z wprowadzaniem metodyk zwinnych niestety jest przyspieszenie całego procesu. Jak już wspominaliśmy nie raz, nie taki jest cel zwinności. Ale takie są zwykle uzasadnienia dość kosztownych transformacji i rewolucji.
Tym dziwniejsze jest ograniczenie całego procesu do bardzo wąskiej grupy, np. tylko do zespołów programistycznych. Wyobraźmy sobie, że w naszym procesie negocjacje z klientem i zbieranie wymagań trwają miesiąc, analiza – kolejny miesiąc, po czym odbywał się development, testy z odbiorami oraz wdrożenie. Jeżeli wszystkie te etapy trwały po miesiącu, to „agile’ując” development sami ograniczamy jakiekolwiek rezultaty do jednej piątej procesu.
Niech i nawet zwinność pomoże nam w przyspieszeniu etapu development o połowę, to i tak zyskamy tylko dwa tygodnie z pięciu miesięcy. Bardzo łatwo o czymś takim powiedzieć, że nie jest warte zachodu. I jestem skłonny się z takim stwierdzeniem zgodzić.
Bo w zwinności wcale nie o to chodzi! Zamiast próbować wtłoczyć stary proces w nową filozofię, należy stworzyć całkiem nową koncepcję. Niech negocjacje trwają i dwa tygodnie, ale od razu po ich zakończeniu zabierzmy się do pracy – analizy, development i testów oraz wdrożeń na raz. Być może w ten sposób zamiast pięciu miesięcy zajmie nam to trzy. A nawet jeśli nie, to na pewno w ten sposób otrzymamy lepsze rozwiązanie i bardziej zadowolonego klienta.
Na ten temat debatowaliśmy w trakcie naszej rozmowy o wdrażaniu się raz w roku. Nie da się ukryć, że bez regularnych wdrożeń nie mamy szans na „bycie agile”. Leżą one u podstaw podejścia zwinnego i po raz setny warto podkreślić, że oddawanie do testów, to nie jest wdrożenie na produkcję. Tylko przekazanie produktu klientowi do docelowego wykorzystania ma szansę zwrócić się w postaci bezcennej informacji zwrotnej.
Ograniczenia pionowe
W tekście zatytułowanym „Jak zmierzyć zwinność” postawiłem tezę, że jedyną metryczką, jaką możemy przypisać organizacji w temacie agile’a jest jego rozpowszechnienie. Jeżeli tylko i wyłącznie Zespoły Scrumowe pracują zwinnie, a cała reszta organizacji swoją elastycznością przypomina beton zbrojony, to niewiele z obiecywanych korzyści się zmaterializuje.
Widzieliśmy sytuacje, w których co prawda cały proces przebiegał zwinnie, ale nie wszyscy mieli świadomość filozofii agile. Powodowało to irytujące sytuacje, w których np. zapotrzebowanie sprzętowe mogłoby być bardzo szybko zrealizowane, gdyby nie konieczność akceptacji dyrektora, który nie chciał słyszeć o jakichkolwiek wydatkach nieujętych w planie rocznym…
Mieliśmy też okazję obserwować jak mikromanagement potrafi zabić zwinność. Jeżeli każda poważna decyzja musi uzyskać akceptację prezesa, to pokazuje to tylko i wyłącznie brak zaufania panujący w danej organizacji. Przecież skoro zatrudniliśmy najlepszych dostępnych na rynku specjalistów, to powinniśmy pozwolić im wykonywać swoją bez ścisłej kontroli. I tak się znają na tym lepiej niż my.
Chyba najpopularniejszym rozdwojeniem jaźni jest sytuacja, w której tylko IT pracuje zwinnie, a reszta firmy – nie. Wtedy na przykład zespoły sprzedażowe działają po swojemu i sprzedają klientom sztywne kontrakty, precyzyjne listy funkcjonalności i jeden ostateczny termin wdrożenia.
Nie tylko utrudnia to jakiekolwiek negocjacje zakresu. Zamyka też drogę do dyskusji o lepszych rozwiązaniach, które mogłyby być wykonane w miejsce niepotrzebnie zgłoszonych wymagań. Co więcej, uniemożliwia także wykorzystanie MVP jako narzędzia do badania potrzeb klienta. Krótko mówiąc, buduje to złe oczekiwania, z których potem bardzo trudno jest wyjść. Pierwsze wrażenie zawsze jest najbardziej trwałe.
Niezależnie od tego, w jaki sposób ograniczymy naszą zwinność, będziemy rozczarowani co do jej rezultatów. Przypomina to sytuację, w której stosujemy metodykę ScrumBut, a oczekujemy efektów Scruma.
Gorsze też jest wrogiem dobrego
Zmiana sposobu działalności organizacji to wielkie wyzwanie. Sami nie raz odbijaliśmy się od drzwi, kiedy ktoś stwierdzał, że nie zaakceptuje takiej formy pracy „i tyle”. Klasyczne „nie, bo nie” wciąż niestety jest popularne i są takie przypadki, w których nie da się przekonać kogoś do lepszego rozwiązania.
Czasami wypracowane przez lata rozwiązania w danej organizacji sprawdzają się bardzo dobrze. Alternatywa w postaci transformacji agile jawi się jako niebezpieczna rewolucja, której krótkookresowe konsekwencje mogą być fatalne. Nie da się ukryć, że zmiany bolą. Zawsze musimy rozważyć zarówno krótko- jak i długoterminowe skutki. Czy warto trwać przy status quo, jeżeli wszystko dookoła się zmienia? Czasami tak, czasami nie.
Echa wszystkiego, o czym mowa w tym tekście można znaleźć w jednym z 5 powodów, dla których Scrum nie zadziała w Twojej firmie, czyli ograniczania Scruma tylko do Zespołów Scrumowych. Scrum to nie jest „przepis na pracę”, ale „filozofia działania”. Tym bardziej jest to prawda, jeżeli mówimy o zwinności w ogóle.
Zawsze gdy będziemy traktować metodykę jako zestaw przepisów i porad, będziemy mieli tendencję do wybiórczego ich stosowania. To tak jak z zaleceń lekarza wybierzemy tylko te, które nie przeszkadzają w naszym stylu życia. Albo gdy z planu treningowego wykreślimy te ćwiczenia, które sprawiają nam największą trudność.
Wśród ludzi spędzających dużo czasu na siłowni popularne jest powiedzenie „ćwiczenie, które sprawia ci najwięcej trudności jest tym, którego potrzebujesz najbardziej”. Trudno odmówić temu porzekadłu głębi. Łatwo jest robić rzeczy, które są lekkie i przyjemne. Ale nie można po nich oczekiwać, że dadzą one wyjątkowe efekty.
Jeśli chcemy stać się agile i jeżeli chcemy coś przez to osiągnąć, nie możemy się ograniczać. Nawet jeśli jest to trudne.
Tematyką organizacji projektów zwinnych zajmujemy się między innymi na naszych szkoleniach otwartych. W naszej ofercie znajduje się także Skalowanie Scrum, gdzie pokazujemy jak stosować Scrum pracując w kilka, kilkanaście i kilkadziesiąt zespołów.
