Blog

Transformacja Agile

Powszechne zainteresowanie metodami z rodziny Agile 17 lat po publikacji Manifestu Agile i po ponad 20 latach wyraźnej obecności tych praktyk (Scruma, Kanbana, XP i in.) w naszej branży, nikogo nie powinno dziwić. Jednak wiele organizacji, które spotykam na swojej zawodowej ścieżce, dopiero rozpoczyna „zwinną transformację” – czyli próbuje agile’owe podejście uczynić standardem swojej organizacji pracy i rozwijania produktów. Najczęściej w firmie zaczyna się od przeorientowania istniejącego działu IT budującego te produkty, następnie przeszkolenia „biznesu” – a więc osób odpowiedzialnych za dostarczanie wymagań i dbanie o wartość rynkową tworzonych rozwiązań, potem (rzadziej na starcie) menedżerów i zarządu, a najrzadziej – samych klientów / odbiorców / użytkowników danego rozwiązania.

Często takie transformacje nie osiągają efektów, czemu się nie dziwię. Na przeszkodzie stoi:

1. zastana kultura organizacyjna (sztywne struktury i hierarchie, rozbuchane procesy, wewnętrzne rozgrywki „polityczne”),
2. powszechna „projektoza”, czyli brak poczucia wspólnoty pracy i obecność „zasobów ludzkich” w czterech projektach na raz, w każdym oczywiście na 100% czasu,
3. brak wyraźnej presji do zmian (firmie nie grozi upadek, nawet gdy nie będzie szybciej tworzyła wartościowych produktów),
4. a jako crème de la crème – brak spójnej wizji, po co taka transformacja w ogóle ma się odbywać!

I nie chodzi jedynie o wyjaśnienie programistom czy project managerom, dlaczego od jutra będą pracować inaczej. Grzechami głównymi źle przygotowanych transformacji są:

1. brak jasnego celu na poziomie wysokich warstw kierowniczych (po co cokolwiek zmieniać),
2. brak porywającej wizji dla całej organizacji (gdzie ta zmiana zaprowadzi naszą firmę),
3. brak przyzwolenia na realną zmianę – zamiast tego tylko naklejanie nowych etykietek na niezmienione role i procesy,
4. brak wiedzy jak mierzyć postępy (jakie metryki i gdzie), skąd będziemy wiedzieć, że osiągnęliśmy cele transformacji,
5. traktowanie zmian nie jako inwestycję, ale jako „zło konieczne” lub „modę na Agile”.

Unifikacja – Scrum dobry w każdym dziale

Jeśli jednak uda się te wymienione grzechy przezwyciężyć lub chwilowo odsunąć w czasie, pojawia się jeszcze jeden – będący owocem burzliwego związku Niewiedzy z Entuzjazmem. Tym grzechem jest potrzeba powszechnej unifikacji.

Kiedy organizacja uczy się metod zwinnych, to najpewniej na starcie zetknie się ze Scrumem, który jest świetnym sposobem na budowanie złożonych produktów wysiłkiem małego, samoorganizującego się zespołu. Największą zaletą Scruma jest bardzo szybka pętla informacji zwrotnej – także o tym wszystkim, czego się wstydzimy: nieznajomości domeny, technologii, potrzeb użytkownika, słabej komunikacji wewnątrz zespołu, niedociągnięć kompetencyjnych, niewystarczającego poziomu jakości itd.

Scrum jednak nie jest uniwersalną odpowiedzią na Największe Pytanie Wszechświata, ma bowiem szereg ograniczeń – wymaga pewnego *setupu* organizacyjnego, poznania nowego sposobu pracy, zrozumienia jego wartości, słabo służy powtarzalnym czynnościom lub obsłudze incydentów itd.

Oczywiście, pewne jego elementy, jak planowanie czy codzienne spotkania, mogą być używane niezależnie od samego Scruma, ale często widzę pełne wątpliwości spojrzenia przedstawicieli działów innych niż IT: „A jak my mamy tak pracować?”. Ambitne plany managementu, działu HR lub komórki odpowiedzialnej za transformację przydzieliły już bowiem pracowników do nowej struktury, nowych zespołów i produktów, a także wysłały ich na nowe szkolenia (ze Scruma najpewniej). Entuzjazm związany ze zmianą i przekształceniami spotyka niewiedzę (Scrum nie jest jedynym narzędziem z rodziny Agile i ma konkretne zastosowania produkcyjne). Jak mają się w tym odnaleźć administratorzy systemów, marketingowcy, prawnicy czy pierwsza linia obsługi klienta? Wszyscy ci, których praca niekoniecznie daje się planować na iteracje i nie zawsze dostarczają produkt jako efekt swojej pracy?

Bez obecności Agile Coacha lub kogoś z doświadczeniami z innych transformacji, może się tu wkraść słuszny lęk i opór przed zmianą, której część zespołu lub załogi nie rozumie i nie widzi w niej swojego miejsca.

Rozwiązanie

Istnieje tylko jedna odpowiedź: oni nie będą pracować w Scrumie, co nie oznacza, że nie mogą pracować zwinnie. Scrum jako taki w działach marketingu, prawnym czy obsłudze call center nie ma wielkiego sensu (co wyjaśniałem kiedyś we wpisie o Scrum vs Kanban). Ale podstawy zwinności: możliwość inspekcji pracy, jej adaptacji oraz utrzymanie przejrzystości wciąż mogą, a nawet powinny być nadal filarami pracy członków zwinnej organizacji. Dlatego z każdym działem trzeba ustalić, jakie praktyki i mechanizmy bedą u nich działać, by wzmacniać samoorganizację, zapewniać przejrzystość procesów oraz gdzie da się „zamontować” mechanizm empiryczny i jak często będzie on używany (jak długa będzie pętla informacji zwrotnej). Dlatego zastosowania różnych technik i praktyk z rodziny Agile będą się pewnie różniły między poszczególnymi częściami organizacji. Nie ma w tym nic złego, ale pod pewnymi warunkami:

1. Istnieje wspólne słownictwo, dzięki czemu zachowana jest przejrzystość. Wiadomo, na jakim etapie znajduje się praca poszczególnych jednostek, kiedy jest ukończona, co znaczą konkretne terminy.
2. Wszyscy w organizacji rozumieją, dlaczego stosuje się mechanizm empiryczny i że oznacza on konieczność *stałego* dostosowywania pracy. Jako taka transformacja jest więc ciągłym procesem, a nie określonym punktem w czasie.
3. Istnieją metryki pozwalające śledzić osiąganie celów całej organizacji bez lokalnych suboptymalizacji. To ważne w kontekście zagrożenia powrotem do pracy w silosach: dział IT znów pracuje na swoje cele, dział sprzedaży na swoje itd.