Blog

Podstawową receptą na zwiększenie wydolności organizacji developerskiej w dużych firmach (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 na raz. Zatrudniona rzesza nowych pracowników jest formowana w zespoły, a management 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 nowo-zatrudnionych 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 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, często lawinowy, efektywności.

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 aby 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 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, jeśli 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ć tej analizy?

Skąd czerpać wiedzę?

Późną wiosną uczestniczyłem w szkoleniu Scaled Professional Scrum, 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 li tylko wypromowaniu 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 nawet przy wprowadzaniu Scruma lub Kanbana na poziomie 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 już 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?