Wyobraź sobie spotkanie, na które zaproszono 14 osób, bo “wszyscy powinni być na bieżąco”. Trwa 90 minut. Realnie pracują w tym czasie trzy z nich. Pozostałe jedenaście sprawdza maile, aktualizuje Jirę albo po prostu czeka, aż będą mogły wyjść. To nie jest patologia – to standard, który większość menedżerów IT zna z własnego doświadczenia, a prawie żaden głośno nie nazywa.
Produktywność zespołu IT to nie to samo co efektywność. Produktywność mierzy się wynikiem na jednostkę czasu, efektywność – tym, czy w ogóle robisz właściwą rzecz. Możesz mieć zespół, który zamyka 60 story points na sprint i dostarcza funkcjonalności, których nikt nie używa. To spektakularnie efektywna bezproduktywność.
Prawo Brooksa wciąż działa – i wciąż go ignorujesz
W 1975 roku Fred Brooks napisał w “The Mythical Man-Month” coś, co od tamtej pory jest cytowane na każdym kursie zarządzania projektami i niemal nigdy nie zmienia zachowania menedżerów: dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej. Mechanizm jest prosty – każda nowa osoba wymaga onboardingu od kogoś, kto już pracuje, a do tego zwiększa liczbę kanałów komunikacji. Przy 5 osobach masz 10 takich kanałów. Przy 10 osobach – już 45. Przy 15 – 105. To nie jest metafora, to kombinatoryka.
Mimo to, gdy projekt się sypie, pierwsza reakcja zarządu to pytanie: “czy potrzebujemy więcej ludzi?”. Sprawdź, ile razy w ciągu ostatniego roku twój zespół dostał nowego członka dokładnie wtedy, gdy był pod presją terminu. I sprawdź, co z tego wynikło.
Badania nad efektem Ringelmanna pokazują ten sam wzorzec od ponad stu lat – im większa grupa, tym mniejszy indywidualny wkład każdej osoby. W kontekście IT potwierdza to analiza 58 projektów open source przeprowadzona przez Scholtes, Mavrodiev i Schweitzer (2016), obejmująca ponad 580 000 commitów i 30 000 deweloperów. Wynik: wzrost liczebności zespołu konsekwentnie koreluje ze spadkiem produktywności per osoba. Jeśli rozważasz skalowanie zespołu, to liczby raczej nie są po twojej stronie.
Struktura organizacyjna produkuje architekturę – czy ci się to podoba, czy nie
Melvin Conway opublikował w 1968 roku artykuł “How Do Committees Invent?” w magazynie Datamation. Jego obserwacja, dziś znana jako Prawo Conwaya, brzmi mniej więcej tak: systemy, które projektują organizacje, są lustrzanym odbiciem ich struktury komunikacyjnej. Innymi słowy, jeśli masz trzy oddzielne zespoły frontendowy, backendowy i bazodanowy, niemal na pewno dostaniesz system z trzema warstwami i interfejsami między nimi, bo inaczej się po prostu nie da pracować.
Spotify wdrożyło ten pomysł odwrotnie – zamiast dostosowywać ludzi do architektury, zaprojektowało strukturę organizacyjną (squady, tribe’y, chaptery, gildie) tak, żeby wymuszała określony kształt systemu. Opisany przez Henrika Kniberga w 2012 roku model zakłada autonomiczne squady odpowiedzialne end-to-end za konkretny fragment produktu. Każdy squad może deployować samodzielnie, bez czekania na decyzję innego zespołu. Zanim zaczniesz kopiować ten model jeden do jednego – Spotify samo przyznało, że z czasem odeszło od jego oryginalnej wersji. Ale samo pytanie, które ten model zadaje (“czy struktura twojego zespołu sprzyja czy blokuje architekturę, którą próbujesz zbudować?”) pozostaje aktualne.
Przyjrzyj się, jak Scrum definiuje granice i odpowiedzialności zespołu – bo jeśli twoi ludzie nie wiedzą, gdzie kończy się ich zakres decyzji, żadna metodologia tego nie naprawi.
Ceremonie Scruma jako generator raportów, których nikt nie czyta
Scrum Guide Schwabera i Sutherlanda (wersja z 2020 roku, dostępna na scrumguides.org) opisuje Sprint Review jako moment inspekcji przyrostu i adaptacji Product Backlogu. W teorii to żywy dialog między zespołem a interesariuszami. W praktyce w wielu organizacjach Sprint Review to pokaz slajdów dla Product Ownera, który i tak wszystko wie, i dla stakeholderów, którzy nie przyszli.
Podobnie z backlogiem – backlog grooming w połowie zespołów istnieje tylko z nazwy, a resztę czasu wypełniają niezapisane decyzje podejmowane na korytarzu. Efekt jest taki, że developerzy trafiają na Sprint Planning z zadaniami, których nikt nie przemyślał, i muszą improwizować szacunki. Mike Cohn w “Agile Estimating and Planning” pokazuje, że to nie problem z ludźmi – to problem z procesem przygotowania pracy, zanim ta praca w ogóle trafi do sprintu.
DeMarco i Lister w “Peopleware” dokumentują coś jeszcze bardziej podstawowego: deweloper potrzebuje średnio 15 minut, żeby wejść w stan głębokiej koncentracji, który autorzy nazywają flow. Jedno przerwanie – maił, ping na Slacku, pytanie od kolegi – i te 15 minut zaczyna się od nowa. Jeśli twój open space generuje 8–10 takich przerw dziennie, to w zasadzie nie masz środowiska pracy. Masz środowisko przerywania pracy.
Standish Group i pytanie, którego nie lubisz zadawać
Standish Group zbiera dane o projektach IT od lat 90. i regularnie publikuje CHAOS Report. Wyniki są raczej niepocieszające i niespecjalnie się zmieniają – mniej więcej jedna trzecia projektów kończy się sukcesem, połowa jest “challenged” (czyli dostarczona z opóźnieniem, przekroczonym budżetem albo okrojonym zakresem), a reszta po prostu pada. Przez dekady branża reagowała na te dane nowymi metodykami. Najpierw PRINCE2, potem PMBoK, potem Agile, potem SAFe. Raporty w zasadzie pozostają podobne.
To sugeruje, że problem produktywności zespołów IT nie leży głównie w metodologii. Leży w tym, co Conway zauważył w 1968 roku, co Brooks opisał w 1975, a DeMarco i Lister skatalogowali w “Peopleware” – w strukturze, komunikacji i środowisku pracy. Narzędzia i frameworki to warstwa na wierzchu. Sprawdź, co masz pod spodem, zanim zmienisz metodologię po raz kolejny.
Źródła
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- DeMarco T., Lister T., “Peopleware: Productive Projects and Teams”, Addison-Wesley, wydanie pierwsze 1987, trzecie 2013.
- Conway M.E., “How Do Committees Invent?”, Datamation, 1968.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Cohn M., “Agile Estimating and Planning”, Prentice Hall, 2005.
- Scholtes I., Mavrodiev P., Schweitzer F., “From Aristotle to Ringelmann: A large-scale analysis of team productivity and coordination in open source software projects”, 2016.
- Kniberg H., Ivarsson A., “Scaling Agile @ Spotify”, Crisp, 2012.
- Standish Group, “CHAOS Report”, wydania cykliczne od 1994.
Zdjęcie: Fiqih Alfarish / Unsplash
