Blog

Podstawową receptą na zwiększenie wydolności organizacji developerskiej w dużych firmach IT (w tych mniejszych pewnie też) jest zatrudnienie większej ilości programistów, testerów i analityków. Trzeba przecież robić więcej, szybciej, wiele rzeczy naraz. Zatrudniona rzesza nowych pracowników jest formowana w Zespoły, a kierownictwo rozpoczyna obserwację słupków statystyk w nadziei, że ich wzrost będzie proporcjonalny do przyrostu ilości łapek na klawiaturach. Po czym następuje rozczarowanie, że tak się nie dzieje, lub przerażenie, gdy słupki opadają.

Dlaczego skalowanie często się nie udaje?

Jeśli zastanowimy się, czemu skalowanie organizacji developerskiej w ogóle miałoby być problematyczne, szybko domyślimy się paru możliwych przyczyn.

Podstawowa i oczywista jest taka, że z tym samym kodem i narzędziami nagle zaczyna pracować dużo więcej osób, rośnie więc prawdopodobieństwo wzajemnego nadeptywania sobie na odciski – nieuniknionego, jeśli nasze „skalowanie” sprowadziło się tylko do zatrudnienia większej ilości osób.

Drugą oczywistą przyczyną jest fakt, że nowozatrudnionych ktoś musi wdrożyć w to, czym mają się zajmować, a to wymaga czasu i zaangażowania tych, którzy do tej pory rozwijali produkt.

Przyczyn może być oczywiście więcej, specyficznych dla każdej organizacji. Na przykład zabójczy może być brak mechanizmów ciągłej integracji (ang. continuous integration) z prawdziwego zdarzenia, źle zdefiniowane produkty i wynikające z tego zależności, brak sensownej wizji rozwoju zarówno produktów, jak i organizacji, złe zarządzanie…

Patrząc nieco szerzej, dostrzeżemy, że problemy ze skalowaniem wynikają z braku umiejętności radzenia sobie z zależnościami – ich eliminowania lub choćby ograniczania. A te będą narastać, gdy przybędzie osób pracujących wspólnie nad jednym produktem. W praktyce dokładanie każdego kolejnego Zespołu nie będzie wcale powodować liniowego wzrostu efektywności całej organizacji developerskiej; w najlepszym razie będzie to wolno wypłaszczająca się krzywa. Po przekroczeniu pewnej granicy (indywidualnej dla każdej firmy), zamiast utrzymać status quo, wywołamy spadek efektywności, często lawinowy.

Jak zrobić to dobrze?

Zamiast zastanawiać się, jak rozbudować Zespół lub dołożyć nowe Zespoły do tych już istniejących, zastanówmy się, jak sensownie wykorzystać to, czym już dysponujemy. Chcemy robić więcej, szybciej i lepiej? Być może by to osiągnąć, wystarczy przestać robić rzeczy zbędne? Być może wcale nie musimy robić wiele rzeczy równolegle albo możemy z części z nich chwilowo zrezygnować, bo i tak mają niską wartość? Być może w istniejących Zespołach tkwią wciąż siły, marnotrawione na spełnianie wymogów organizacji i arbitralne procedury?

Dopiero gdy jesteśmy pewni, że zatrudnienie nowych ludzi jest nieuniknione, zróbmy to. Kiedy to będzie miało sens? Na pewno wtedy, gdy zaczynamy tworzyć nowy (drugi, kolejny) produkt, albo gdy znacząco rozbudowujemy to, nad czym pracowaliśmy do tej pory. Musi to być ekonomicznie opłacalne, czyli dawać więcej korzyści niż powoduje problemów.

Jak dokonać takiej analizy?

Późną wiosną uczestniczyłem w szkoleniu Scaled Professional Scrum (SPS), prowadzonym przez Andy’ego Brandta, na którym z wielu perspektyw omawiany jest temat skalowania Agile. Szkolenie związane jest z frameworkiem Nexus zaproponowanym przez Scrum.org, natomiast nie skupia się tylko na metodzie, dotykając wszelkich aspektów skalowania. Tak po prawdzie śmiało można by podmienić Nexus w czasie tego szkolenia na LeSS i wciąż miałoby ono sens – co jest dobrym probierzem tego, że szkolenie (SPS) nie służy tylko wypromowaniu konkretnej metody.

Wspominam o szkoleniu, bo zapadły mi w pamięć dwie rzeczy. Pierwsza: nie byliśmy przekonywani, że istnieje gotowa, sprawdzona i zawsze działająca recepta na skalowanie Agile – zamiast tego Andy (ale też i Scrum.org) mówił wprost, że od pewnego poziomu to, jak skalować, zależy od organizacji i jej specyfiki, a wszelkiego rodzaju frameworki mogą stanowić jedynie inspirację i zbiór dobrych praktyk. Gdyby się zastanowić głębiej, jest to prawdą nie tylko dla skalowania Agile, ale również przy wprowadzaniu Scruma lub Kanbana do jednego Zespołu w małej firmie…

Druga, chyba jeszcze cenniejsza rzecz z tego szkolenia, to możliwość spotkania ludzi, którzy w praktyce ze skalowaniem się mierzą (lub kiedyś musieli się zmierzyć). Ponieważ SPS nie jest szkoleniem dla początkujących, uczestnicy równie wiele, co od trenera, uczą się od siebie wzajemnie. W ten sposób na skalowanie zamiast z jednego punktu widzenia (własnego) można popatrzyć z wielu perspektyw.

A jak skalowanie wygląda w waszych organizacjach? Czy wartością nadrzędną jest rozrastanie się w myśl zasady, że im coś większe, tym musi być lepsze? Czy też zdrowy rozsądek powstrzymuje was od poszukiwania łatwych rozwiązań i staracie się uzyskać maksimum możliwości z tego, czym już dysponujecie?