W czerwcu 2015 roku ING Bank w Holandii rozwiązał ponad 3500 stanowisk i poprosił ludzi, żeby złożyli podania o pracę w nowej strukturze. Nie było reorganizacji w stylu “przesuniemy kilka kratek na organigramie”. Firma dosłownie wymazała dotychczasowy podział na działy IT, marketingu i operacji, a w ich miejsce powołała około 350 squadów po maksymalnie 9 osób, zgrupowanych w 13 tribach. Każdy squad miał mieć w środku wszystko, czego potrzebuje do dostarczenia produktu – developera, analityka, kogoś od UX, czasem prawnika. Bez czekania na zasoby z zewnątrz.
To był radykalny zakład. I zadziałał – przynajmniej na tyle, żeby McKinsey opisał go jako wzorzec transformacji agile’owej w finansach. Ale zanim zaczniesz myśleć o powieleniu tego w swojej firmie, przyjrzyj się, co sprawiło, że w ogóle było to możliwe – i dlaczego w większości organizacji podobne próby kończą się squadem z nazwą, ale bez autonomii.
Prawo Conwaya wisi nad każdym projektem
Melvin Conway sformułował swoją obserwację w 1968 roku w artykule dla Datamation: organizacje projektują systemy, które odzwierciedlają ich własną strukturę komunikacyjną. Brzmi akademicko, ale w praktyce oznacza to, że jeśli masz osobny dział backendu, osobny front i osobny QA – twój system będzie miał twarde granice dokładnie w tych samych miejscach. Integracje będą bolesne, bo bolesna jest komunikacja między działami.
Zespół cross-funkcyjny to w pewnym sensie próba odwrócenia tego mechanizmu. Zamiast dostosowywać architekturę do struktury – zmieniasz strukturę pod pożądaną architekturę. Tyle że większość firm robi to połowicznie: powołuje cross-funkcyjny team, ale zostawia każdemu specjalistę z poprzednim szefem, poprzednim budżetem i poprzednim systemem oceny wyników. Squad istnieje na papierze, ale lojalność każdego członka ciągnie gdzie indziej.
Sprawdź, czy twój “cross-funkcyjny” zespół ma wspólny backlog. Jeśli developer z działu IT i analityk z biznesu raportują do różnych dyrektorów i każdy ma swoje osobne OKR‑y – to nie jest jeden zespół. To delegacja robocza z różnych departamentów, która spotyka się na Daily.
Efekt Ringelmanna i mit dużego zespołu
Maxime Ringelmann, francuski inżynier rolnictwa, udowodnił już pod koniec XIX wieku, że im więcej osób ciągnie linę, tym mniejszy wysiłek wkłada każda z nich. Badania nad tym efektem potwierdzają to samo w pracy umysłowej – w dużej grupie jednostkowa odpowiedzialność rozmywa się. Scrum Guide nie bez powodu mówi o zespołach między 3 a 9 osób. SAFe, który obsługuje znacznie większe struktury, dzieli Agile Release Train na teamy właśnie po 5–11 ludzi, żeby utrzymać ten próg.
Wyobraź sobie projekt migracji do chmury: 20 osób z czterech działów, dwa razy w tygodniu status meeting, Jira pełna tasków bez właściciela. Kto odpowiada za decyzję o architekturze storage’u? Wszyscy i nikt. Po trzech miesiącach okazuje się, że dwie podgrupy równolegle robiły to samo, bo nikt nie wiedział, że tamci już zaczęli. To nie jest patologia – to statystyczna norma w zespołach, które przekroczyły rozsądny rozmiar bez jasnego podziału odpowiedzialności.
Trzy filary Scruma, które wszyscy znają i połowa zespołów ignoruje – jeśli twój zespół ma problemy z przejrzystością odpowiedzialności, warto zacząć od sprawdzenia, czy te fundamenty w ogóle działają, zanim dołożysz kolejną warstwę cross-funkcyjności.
Kiedy “cross-funkcyjny” znaczy “każdy robi wszystko” – i dlaczego to nie to samo
Jeden z częstszych błędów przy budowaniu takich zespołów to mylenie wielofunkcyjności z brakiem specjalizacji. Cross-funkcyjny squad w modelu Spotify czy w SAFe nie oznacza, że developer nagle projektuje UX, a designer deployuje na produkcję. Oznacza, że wszystkie kompetencje potrzebne do dostarczenia wartości są fizycznie w jednym miejscu – bez ticketów do innego działu, bez czekania w kolejce zasobów.
DeMarco i Lister w “Peopleware” opisali to zanim ktokolwiek użył słowa “squad”: najefektywniejsze zespoły to te, które mają przestrzeń do budowania własnej tożsamości i rytmu pracy. Mieszanie zbyt wielu domen naraz – IT, HR i finanse w jednym projekcie wdrożeniowym – tworzy inny problem: każda profesja ma swój własny słownik, własne priorytety i własne rozumienie słowa “gotowe”. Definicja of Done w Scrum Guide zakłada wspólne kryterium akceptacji. W praktyce prawnik mówi “gotowe” gdy zaakceptował dokumentację, developer gdy kod przeszedł testy, a biznes gdy zobaczy demo. Trzy różne “gotowe” w jednym sprincie to przepis na Sprint Review, który nic nie kończy.
Backlog grooming – ceremonia, która w połowie zespołów istnieje tylko z nazwy – w cross-funkcyjnych teamach ten problem uderza ze zdwojoną siłą. Grooming wymaga wspólnego języka, a tego nie ma od pierwszego dnia.
Co sprawia, że to naprawdę działa
Wróćmy do ING. Sukces tamtej transformacji nie wziął się z samego podziału na squady – wziął się z trzech równoległych decyzji, które organizacja podjęła jednocześnie. Po pierwsze, każdy squad dostał realny budżet i mógł decydować o narzędziach bez zgody centralnego IT. Po drugie, system oceny wyników zmienił się tak, żeby nagradzać wyniki squadu, nie indywidualny KPI. Po trzecie, fizyczne biuro zostało zaaranżowane tak, żeby squad siedział razem – nie po działach.
Bez tych trzech elementów cross-funkcyjny zespół to raczej komitet z nową nazwą. Możesz go zbudować w jeden dzień w Jirze. Ale czy twoi ludzie wiedzą, kto ma ostatnie słowo w sporze między perspektywą techniczną a biznesową? Czy mają do tego mandat, czy za każdym razem eskalują do dyrektora? To pytanie, na które warto znać odpowiedź zanim zmienisz organigramm.
Źródła
- Conway M.E., “How Do Committees Invent?”, Datamation, 1968.
- DeMarco T., Lister T., “Peopleware: Productive Projects and Teams”, Dorset House, 1987.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Scaled Agile, Inc., “SAFe Framework”, scaledagileframework.com.
- McKinsey & Company, “ING’s agile transformation”, mckinsey.com, 2017.
- Badania nad efektem Ringelmanna – prace Ringelmanna z przełomu XIX i XX w., zreplikowane m.in. przez Latane, Williams i Harkins w Journal of Experimental Social Psychology, 1979.
Zdjęcie: One-Small-Step / Pixabay
