Dlaczego agile nie działa poza IT?

Agile poza IT jest chwytliwy – nieustannie widzę reklamy szkoleń tego typu, temat podchwytują konsultanci. Pojawia się AgileHR, AgileMarketing. Jedno z pierwszych pytań, jakiego spodziewam się na każdej prezentacji o transformacji, jest „jak wygląda Wasz agile poza IT?”. Być może jest to jeszcze jeden przypadek czegoś, co wszyscy słyszeli, chętnie by robili, ale sami nie dają rady. Na AgilePoznan pojawiło się pytanie o to, dlaczego moim zdaniem agile poza IT nie zadziałał w firmach, w których byłem. Moim zdaniem wynika to mocno z tego, że zwłaszcza poza IT jest silna tendencja do odbierania zwinności jako mechaniki (np. Scrum to systematyka spotkań, kanban to tablica z taskami).

Uruchamiane są inicjatywy zwinnej pracy w biznesie (= poza IT) przez menedżerów biznesowych, którzy kompletnie nie czują, jakie fundamenty stoją pod spodem tego, że zespół programistów spotyka się w jakiś sposób, używa kolorowych gadżetów i nazywa się wzajemnie śmiesznymi tytułami. Moja subiektywna lista, tego co nie działa w próbach realizacji pracy zwinnie poza IT poniżej:

• Ludzie są oddelegowani do zespołu zwinnego i ich kierownik nie rezygnuje z osobistej możliwości (mikro)zarządzania swoim człowiekiem. Członek zespołu zwinnego nie ma umożliwionej samoorganizacji, ponieważ nie ma zdelegowanej odpowiedzialności za decyzje ani nawet swobody pracy według swoich pomysłów.
• Osoby oddelegowane do pracy w zespole zwinnym nie są dedykowane do tych działań. Mało tego – z tego co widzę to odesłanie do zespołu jest kompletnie nieplanowalne, na zasadzie „masz robić projekt oraz wszystkie poprzednie swoje obowiązki” i bieżączka wygrywa z jakimkolwiek planem zespołu.
• Realizowane jest podejście w zamierzeniu zwinne, ale nie jest stosowana samoorganizacja. Członkowie zespołu mają wręczane zadania do wykonania (wprost albo lider projektu czeka aż „ochotnik” wreszcie się zreflektuje że ma się zgłosić). Członkowie zespołu twardo trzymają się swoich silosowych specjalizacji, z którymi przyszli do zespołu i ani na krok z nich nie wychodzą. Jak nie ma zadania dla tej specjalizacji, to natychmiast wraca do swojej bieżączki pozazespołowej
• Nie jest stosowane podejście „pull” (z kanbana) albo zasada, że zespół bierze na iterację tyle pracy, ile czuje, że jest w stanie wykonać. Zadania są ładowane na taczkę tak długo, aż upłynie czas przewidziany na spotkanie statusowe projektu.
• Zwinność jest używana do realizacji projektu,  co automatycznie we wszystkich członkach zespołu i zarządzających nad zespołami uruchamia odruchy zarządzania projektem. Dąży się do planu projektu i harmonogramu, ważny jest zakres, oczekuje się odpowiedzialności jednoosobowej ze strony jakiegoś PMa. Cel projektu ustawia się na zakresie i terminie, co czyni bezsensownym próby eksplorowania przez zespół innych opcji niż ta, która ustalona jest na samym początku (np. skoro celem jest zrobić 10 szkoleń, to zrobimy 10 szkoleń… nie ważne że po 5 już widzimy że nie dają efektów o które nam chodziło).
• Na etapie startowania takiego zespołu nie ustala się, co jest produktem pracy zespołu (i nie powinien to być zakres projektu planowany przed uruchomieniem prac). Uruchamia się struktury organizacyjne odpowiednie do pracy nad zagadnieniami złożonymi, ale na poziomie zakresu i celu zarządzający trzymają się kurczowo koncepcji z domeny skomplikowanej (np. celem i zakresem pracy zwinnej jest „zrealizować akcję informacyjną” a nie „wpłynięcie nową informacją na odbiorcę docelowego”). Zamiast znaleźć złożony problem wymagający długofalowej pracy w miarę stałego zespołu zadaniowego, zbyt wąsko dookreślone i uproszczone sformułowanie celu projektu automatycznie rozwiązuje zespół po zamknięciu etapu projektu.
• Podejście przyrostowe nie jest stosowane. Praca zespołu zwinnego usztywniana jest założeniem, że efekty pracy widoczne będą dopiero na samym końcu projektu. Wynika to najczęściej z mixu poleceniami przełożonych, przekonaniami w zespole i brakiem umiejętności. „Nie da się” wdrażać cząstkowe rozwiązania wcześniej, weryfikować hipotezy, korygować kurs do którego zespół zmierza.
• Nie marnuje się czasu na takie trywialne rzeczy jak ciągłe i cykliczne usprawnianie się. Wszystko przecież idzie sprawnie do przodu i oszczędzając godzinę spotkania przynajmniej szybciej skończymy ten projekt.
• Zarządzający nie rozumieją, że istnieje konieczność powoływania coacha procesu zwinnego (Scrum Master, Agile Coach) lub rola ta wręczana jest osobie niekompetentnej. A jeśli jakiś kompetentny coach jest – nie słucha się go, zarządzający cierpliwie pracują na to, by jego pozycja i jego pomysły były podważone (np. wspomniana przyrostowość której się nie da zrobić albo będzie zbyt kosztowna, więc stosowane są naciski na członków zespołu by tak nie pracowali)

Co robić, żeby uniknąć tych błędów – zadbaj, żeby w projekcie zwinnym istniały zjawiska, które w powyższym tekście wyboldowałem. Możesz też zainteresować się moim webinarem o agile, gdzie definiujemy z Jackiem Wieczorkiem „Co to jest Agile?„. Webinar skupia się na istocie zwinnościa, bez wchodzenia w szczegóły Scruma czy innej konkretnej metody zwinnej.