.st0{fill:#FFFFFF;}

Ewolucja, a nie rewolucja 

 28 kwietnia, 2020

Tomasz Dzierżek

Czy da się sprowadzić do jednego mianownika kilkaset albo nawet kilka tysięcy pracujących osób? Bardzo często tak właśnie wyglądają pomysły na transformacje i przejście na zwinną stronę mocy. My, jako #białko, zwykle opowiadamy się za ewolucją, a nie rewolucją. Dlaczego?

 

„Specyfika naszej pracy…”

Zdania zaczynające się od „Specyfika naszej pracy…” są nieustającym running joke na naszych szkoleniach i warsztatach. Prawie każdy, kogo spotykamy wierzy, że jego sytuacja jest wyjątkowa. Ale patrząc z boku widać, że podobieństw jest więcej niż różnic. I to niezależnie czy chodzi tutaj o sposób pracy, problemy operacyjne, czy też podejście projektowe.

To nie jest tak, że mamy nieskończoną paletę problemów, z którymi się borykamy. W skali mikro bardzo dobrze widać to na przykładzie Scrum Masterów, którzy po zaledwie kilku latach spędzonych w małych i dużych organizacjach napotykają na co najmniej 80% możliwych do wystąpienia problemów (patrz: Zasada Pareto).

Nie ma w tym nic dziwnego, bo niektóre rzeczy związane ze współpracą międzyludzką występują zawsze w przypadku grup ludzi, a inne – jedynie bardzo często. I tak w końcu docieramy do momentu w którym wydaje nam się, że „wszystko to już było”.

Podobnie sytuacja ma się w skali makro, jeżeli chodzi o transformacje agile i zmiany w sposobie organizacji pracy. Tu problem z nabyciem odpowiedniego doświadczenia przez Agile Coachów jest większy, bo niektóre problemy pojawiają się dopiero po latach. Zresztą, sama reorganizacja dużych firm to to też proces na co najmniej kilka, a może i kilkanaście miesięcy.

Czy jednak to nie sugeruje, że i w tym przypadku mamy „katalog kłopotów” i niezależnie od tego, jaka jest „specyfika naszej pracy” możemy wziąć jakieś standardowe podejście albo metodykę i nałożyć ją na całą organizację liczącą setki bądź tysiące osób?

 

Ewolucja, a nie rewolucja

Przy okazji omawiania tematu Sprint Retrospective zawsze podkreślamy, że nie ma sensu zabieranie się za więcej niż dwa-trzy usprawnienia per Sprint. Jeżeli spróbujemy wprowadzić więcej to zwykle część z nich w ogóle się nie zadzieje, a nawet jeśli, to będziemy mieli inny problem. Zmieniając wiele rzeczy nie będziemy mieli pojęcia, które z nich pomogły, które zaszkodziły, a które nie zmieniły nic.

Mamy zresztą na ten temat film o jakże wdzięcznym tytule „Jak przeprowadzać zmiany?„. Podkreślamy w nim, że zmiany należy wprowadzać stopniowo i dokładnie mierzyć, jaki mają one wpływ na naszą pracę. To przecież właśnie ten słynny empiryzm.

Analogicznie, jeżeli chcemy przeorganizować nasz projekt, dział czy całą firmę, to w przypadku rewolucji możemy mieć problem z mierzeniem efektywności. I tu warto podkreślić, że w większości przypadków w ogóle nie jest to konieczne. Jeśli chcemy pracować zupełnie inaczej i przeorganizowujemy przy tym wszystko – od procesów do zespołów – to nawet nie mamy do czego się porównywać. Przesiadając się z samochodu na motorówkę nie będziemy przecież porównywać niczego, bo te pojazdy mają ze sobą tylko tyle wspólnego, że oba potrafią się poruszać.

I tu dochodzimy do paradoksu rekomendacji #białko. Z jednej strony mówimy „wprowadzajmy metodyki w całości, a nie po kawałku”, a z drugiej krzyczymy „ewolucja, a nie rewolucja”. Czas wyjaśnić nasze stanowisko.

 

Hurtowa optymalizacja zespołów

Różnicę robi nam fakt, że tworzymy coś zupełnie nowego. Jeśli zaczynamy nowy rozdział w pracy naszej organizacji, to odcinamy wszystko grubą kreską i budujemy nowe zespoły, tak naprawdę tworząc wszystko od zera. Czy to jest „rewolucja”? Nawet jeżeli tak, to jestem tutaj w stanie przyklasnąć i podnieść oba kciuki do góry.

Bo alternatywą jest coś, co roboczo nazywam „hurtową optymalizacją zespołów”, która odbywa się w przypadku transformacji robionych na siłę dla wszystkich. Widziałem organizacje, które brały kilkadziesiąt zespołów pracujących każdy w inny sposób i te kilkaset osób próbowały wcisnąć w ramy np. Scruma.

Każdy zespół, oglądany jako całość, jest na innym etapie rozwoju i boryka się z innymi problemami. Trudno sobie wyobrazić, żeby wszyscy przeszli to samo szkolenie i zaczęli działać w ten sam sposób. „Róbcie to samo co wcześniej, tylko kompletnie inaczej” nie zadziała. Tu niezbędna jest ewolucja i dochodzenie do stanu docelowego krok po kroku.

Ba! Jeżeli mamy heterogeniczne środowisko, to często najlepszym wyborem będzie działanie iteracyjne i przyrostowe. Mówiąc wprost: zacznijmy zmieniać zespół po zespole, projekt po projekcie i w ten sposób rozpocznijmy naszą przygodę ze zwinnością.

 

Stan zastany

Pamiętajmy, że jeśli nie startujemy niczego nowego (nowy projekt, nowe zespoły, nowa organizacja) to mamy jakiś stan zastany. To znaczy jedne zespoły będą wymagały więcej uwagi niż inne. Niektóre obszary będą musiały być potraktowane specjalnie, a inne nie w ogóle nie będą gotowe na pracę zwinną. W takim przypadku zalecamy działania ewolucyjne, nie rewolucyjne.

Alternatywą, i to wyjątkowo skuteczną, jest budowa czegoś nowego od zera. Ale wtedy nie oszukujemy się, że „transformujemy zespoły”, bo tak naprawdę tworzymy nowy projekt czy dział. Widziałem sytuacje, w których takie nowe konstrukcje trafiały do zupełnie nowych biur i przestrzeni. Wtedy wszyscy czujemy, że jesteśmy czymś nowym i łatwo jest zerwać ze starymi nawykami i zaakceptować nową rzeczywistość.

Podsumowując, „budowa nowego projektu czy działu w oparciu o konkretne podejście lub metodykę” – tak, ale już „nauczenie dwustu osób Scruma, bez zmiany składu zespołów, otoczenia biznesowego i mindsetu” – nie.

To po prostu nic nie da.

Tomasz Dzierżek


21+ lat doświadczenia w IT, 13+ lat doświadczenia w Scrum i agile, PSM I-III, konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}