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.

2 odpowiedzi do “Dlaczego agile nie działa poza IT?”

  1. Interesting arguments indeed, Kuba. However, I would add my observation. If we speak about Agile in IT, in my observation nearly 90% of all use was pure mechanistic deployment of Scrum or board in Kanban. So I wouldn’t exaggerate expertise of IT in Agile. And why Agile beyond IT does not work? It is more complex question to be answered. First Agile as techniques to improve performance was born outside IT, under different names. And copied later into IT – where process of „discovering” is still in progress. It is like „language barrier”.

    There exist organization, which behaves agile across all functions. But most companies are built as group of silo-functions. These silos work pretty independently from each other driven by its own objectives only – a bureaucracy. Once organization grows in size, bureaucracy tends to increase and live by its own life, resulting in politics. There is also one special case – as long as company is listed on stock exchange, suddenly there are other objectives than serving customers.

    Agile expects engaged and knowledgeable people willing to create and experiment, while courageous enough to be accountable for outcome. Those are however rare species in general population. And even those needs to be educated. In my entire career I met only handful of managers capable see big picture and act accordingly, define vision and searching for ways to implement it.

    Problem I see also with „agile coaches”. Majority of them comes from IT, with no life experience. They read something about Scrum and Agile (IT related), implement mechanistic process into dev team and want to see mechanistically other parts of the organization. Most people in other functions does not have so structured and mechanistic world view.

    If you want to see more Agile working beyond IT and let say across whole organization, there needs to be better definition of vision for the company, not only what company wants to do but also how will become very important. We need quality managers, who see their role as profession and endlessly works on their improvement in it. I do not think there will be space for coaches, because managers are supposed to be coaches to their people themselves. And this require managers see their role as profession, not as a temporary place where they have got promoted. Then they will be able to design strategies for engaging people and challenge traditionalistic view of organizational set up and design better value driven and innovative configuration – capable to provide space for those proactive people and still get most of those passive ones. The future will bring many challenges in this.

  2. Thanks Michal for the comment, I generally agree with your additions.

    In particular I agree with this:
    > I do not think there will be space for coaches, because managers are supposed to be coaches to their people themselves

    I enjoyed reading Radical Management by Steve Denning, who on purpose named the role of Process Coach. In Scrum we have Scrum Master, but in more general agile approach (suitable for Agile outside IT) it might be anyone, including manager. But such manager has to have responsibility not only to deliver (the team that delivers the) outcomes but also to create an environment, to be the coach of the process of delivering the outcomes. Some will say it’s just a good manager, others will argue that it has to be someone specialized only in agile approach. I didn’t want to start this discussion, hence the phrase „istnieje konieczność powoływania coacha procesu zwinnego”.

    See you in Olomouc during Agile Conference! 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *