Pisałem tę artykuł trochę dla siebie, żeby podsumować kilka spostrzeżeń. No, ale skoro już napisałem, to pomyślałem, że opublikuję. Dobrej zabawy :)

Jest na rynku pewna kategoria firm, którą można by nazwać "firma za duża, aby być mała". Jest to, któryś tam z etapów rozwoju organizacji. Najczęściej założona przez dwóch lub więcej specjalistów, projekty się robią, klienci wracają, ludzie przychodzą do pracy. Słowem kręci się. Procesy pracy takiej firmie rozwijają się organicznie poprzez sieć naturalnych kontaktów.

Punkt przegięcia

W pewnym momencie następuje punkt przegięcia. Moim zdaniem wyróżnikiem tego momentu jest osiągniecie przez organizację liczności ok. 60 osób. Wtedy w widoczny dla wszystkich sposób, praca zaczyna kuleć. Ponieważ skalowanie pociąga za sobą również skalowanie błędów to każde niedogadanie, które do pewnego momentu można było rozwiązać krzycząc przez korytarz do drugiego pokoju, jawi się teraz jako chaos.

Zauważyłem, że jednym ze stosowanych rozwiązań jest wtedy spisywanie i ogłaszanie oficjalnie obowiązujących procesów. Nie mam nic przeciwko standaryzowaniu procesów i jestem wielkim fanem ładu organizacyjnego. Jednak usprawnianie organizacji poprzez opublikowanie procedur jest nieskuteczne. Bywa nawet, że zatrudniani są na etat spec lub specna, których jedynym zadaniem jest uporządkowanie procesów. Wizyty takowych na każdym spotkaniu bardzo poprawiają humor inżynierom. Zwłaszcza, że specom od spisywania procesów zdarza się przysnąć na refinemencie. Jak wiadomo robienie czegokolwiek uspokaja i może się zdarzyć otrąbienie sukcesu na podstawie księgi procedur.

Doprecyzowanie kontekstu

Poniższy przykład dotyczy firmy, która

• liczy ok. 60 osób,
• ma własny dojrzały produkt wdrażany u wielu klientów,
• prowadzi dużo custom dewelopmentu
• mniej więcej taki podział: Zespół PMów, Zespół Developerów, Zespół Frontendu, Zespół Testerów, kilkoro sprzedawców
• znikoma liczba stanowisk nie-IT: księgowość, HR, Zarząd

Kluczowe problemy

Na tym etapie rozwoju organizacji ja widzę powtarzany zestaw problemów.

Oczekiwania klientów rozwalają architekturę. To to bardzo charakterystyczny problem w organizacjach świadczących usługi b2b i wdrażających swój produkt u wielu klientów. W mojej opinii na powstanie tego problemu przede wszystkim składają się nastepujące czynniki:

• pojedyncze kontrakty mają istotny udział w przychodzie organizacji - kontrakty są duże, klienci są duzi i dużo wymagają
• bywa, że organizacja jest uzależniona od jednego dużego klienta
• sprzedawcy są rozliczani z wolumenu sprzedaży; nie biorą pod uwagę kosztów, jaki generują haki w kodzie,
• sprzedawcy starają się maksymalizować prowizję, która jest zależna od wolumenu sprzedaży
• przed Zarządem głos Sprzedaży jest ważniejszy niż głos Developmentu
• jeśli w firmie obecny jest inwestor z kapitałem, to oczekuje on od Zarządu dwucyfrowego wzrostu rok do roku, co tym bardziej wywiera presję na Zarząd, aby preferować głos Sprzedaży

Ostatecznie Development musi się bardzo napocić, aby ochronić architekturę. Kolejne parametry, kolejne customizacje, kolejne ify w kodzie, oznaczają kolejne punkty do złożoności cyklomatycznej, a to oznacza kolejne trudności z testowaniem i utrzymaniem. Długoterminowo oznacza to również problemy z wydajnością, dalszym rozwojem systemu, pozyskaniem pracowników.

Znajomy Dyrektor IT powiedział mi kiedyś, że ludzie potrzebują fajnego produktu, z którym mogliby się identyfikować. Wyżej opisany produkt zdecydowanie nie jest fajny.

W trakcie planowania prac PMowie konkurują o inżynierów. PMowie mają przydzielonych klientów. Jak uczy doświadczenie, czasu zawsze jest zbyt mało. Toteż PMowie w trakcie planowania prac konkurują między sobą o czas developerów, testerów, UXów, administratorów itd.

Testy nie mieszczą się w deadlines. W konfiguracji, którą opisuję testerzy grupowani są w osobnym zespole. Podawane uzasadnienie jest najczęściej takie, że wtedy efektywniej zarządza się ich pracą. Ostatecznie testowanie odbywa się wykonaniu dewelopmentu i jest na nie przeraźliwie mało czasu. To z kolei powoduje, że gdy deweloperzy planują prace i doprecyzowują wymagania, testerzy mają po uszy roboty z poprzednim releasem. Gdy natomiast testerzy już się uporają z robotą i chcieli by się czegoś dowiedzieć o kolejnej, to deweloperzy nie mają czasu, bo staraj się jak wypchnąć aktualny kod jak najszybciej do testów.

Klienci nie umieją współpracować z IT. Głównie chodzi o dostępność i intensywność współpracy. Charakterystyczna postawa jest następująca: powiem Wam o co mi chodzi i wróćcie do mnie, gdy już będzie gotowe.

Wymienione problemy przedstawiłbym następująco jako graf przyczyn i skutków.

Jeśli nie widzisz tablicy, tutaj jest link https://miro.com/app/board/o9J_l1Zuies=/

Scrum?

Scrum czy inny framework prozwinny są aktualnie na tapecie. W tych też kierunkach zarządzający organizacjami szukają rozwiązań ww. bolączek. Jednak procesy adaptacyjne takie, jak Scrum wymagają do działania pewnych założeń min. spójność celów, przejrzystość, wzmocnienie decyzyjności inżynierów.

Jeśli w tym opisie odnajdujesz swoją organizację i myślisz o zwinnej transformacji, to wiedz, że moim zdaniem w momencie, który opisuję jest na to za wcześnie. Nie każdy kod może zostać zrefaktoryzowany, trzeba najpierw doprowadzić do postaci, z której można zacząć refaktoryzację np. stosując NCR. Podobnie nie w każdej organizacji da się wdrożyć zwinny framework, najpierw trzeba tę organizację doprowadzić do postaci gotowej do uzwiniania.

Jak to zrobić? Mam na tę okazję - wciąż podkreślam, że dotyczy to organizacji, które odnajdują się w niniejszej charakterystyce - siedem zaleceń ;) Kolejność jest ważna.

1. Zasady nadawania priorytetów

Konkurowanie PM o czas developmentu prowadzi jedynie do tego, że wygrywa projekt, którego właściciel najgłośniej krzyczy albo ma chody u prezesa. Ostatecznie w kontekście całej organizacji może być to kiepski wybór.

Zatem wspólnie z PMami/właścicielami projektów, sprzedażą oraz Zarządem należy wprowadzić jednoznaczne i zasady nadawania priorytetów projektom. Nawet jeśli zasada będzie brzmieć "najwyższy priorytet ma najbardziej dochodowy projekt" to jest ona lepsza niż brak jawnie wyartykułowanych zasad.

Zasady powinny zostać upublicznione, aby dla każdego inżyniera było całkowicie jasne, z jakiego powodu dane zadanie jest ważniejsze od pozostałych.

Każde planowanie ma odbywać się w oparciu o ustalone zasady, a nie jako efekt konsensu PMów.

2. Tempo pracy

Wprowadzić stałą długość iteracji w całej organizacji i zsynchronizować prace z okienkami releasów. Stała długość iteracji jest podstawą do mierzenia oraz budowania przewidywalność zespołów.

3. Regularne usprawnianie

Zamiast projektowych post mortem wprowadzić mniejsze retrospektywy po każdej iteracji. Zapewnić odpowiednią moderację. Dopilnować wdrażania ustaleń.

4. Refinement

Zostawić w spokoju chwytliwe memy typu "planning poker". Są one łatwe do natychmiastowego zastosowania, ale w na tym etapie nie mają żadnej wartości. Zamiast tego przyłożyć wielką wagę do regularnego refinementu, aby inżynierowie znali i rozumieli wymagania przed rozpoczęciem pracy. Można do tego wykorzystać metody warsztatowe.

5. Pomoc z zewnątrz

Zatrudnić na full time doświadczonego Scrum Mastera/Kanban speca. Taka osoba powinna spełniać następujące kryteria:

• ma jakieś doświadczenie inżynierskie
• ma jakieś doświadczenie managerskie
• parę rzeczy w życiu mu/jej nie wyszło - ma dystans i pokorę

Od Scrum Mastera / Kanban speca koniecznie wymagać, aby przeprowadził diagnozę organizacji i przedstawił plan swojej pracy.

Wspólnie zatrudnioną osobą wdrażać kolejne elementy Scruma lub innego frameworka adaptacyjnego.

6. Pełnokompetentność

Wprowadzić zespoły pełnokompetentne czyli takie, które posiadają pełnię kompetencji do wykonania pracy. Preferować zespoły o stałym składzie ponad zespoły tworzone na potrzeby projektu. Oczywiście jeśli jest to efektywne kosztowo.

7. Architektura, która wspiera zwinność

Zwinność to uzyskiwanie przewagi konkurencyjnej dzięki technologii. Nie dzięki samym procesom, ale przede wszystkim dzięki technologii.

Zatem należy wprowadzić architekturę, która wspiera zwinność.

Zaplanować reorganizację architektury tak, aby w ogóle zrezygnować z releasów. Zespoły powinny móc wdrażać się niezależenie.

Dążyć do przesunięcia testowania jak najbardziej na lewo, do automatyzowania wszystkich możliwych powtarzalnych czynności, aby jak najefektywniej wykorzystać pracę inżynierów.