W 2015 roku ING Bank uruchomił jeden z głośniejszych eksperymentów w europejskiej bankowości. Podzielił kilka tysięcy pracowników na około 350 dziewięcioosobowych squads zgrupowanych w 13 tribes, wziął model organizacyjny wprost ze Spotify i zaczął dostarczać funkcje produktowe w dwutygodniowych sprintach. Efekt był widoczny: skrócił się czas wdrożeń, wzrosło zaangażowanie zespołów. Tylko że ING to bank, który zatrudnia dziesiątki tysięcy ludzi na trzech kontynentach i działa pod nadzorem regulatorów. Spotify, gdy opisywało swój model w słynnych filmach z 2014 roku, miało ułamek tej skali i żadnej regulacji ostrożnościowej. ING i tak wyciągnął z tego coś działającego. Ale nie dlatego, że skopiował strukturę – raczej dlatego, że zrozumiał, co pod nią leży.
Na czym naprawdę polega transformacja cyfrowa
Transformacja cyfrowa to zmiana sposobu, w jaki organizacja tworzy i dostarcza wartość, przy użyciu technologii jako dźwigni. Brzmi prosto, dopóki nie okaże się, że zmiana dotyczy procesów, struktury, kultury i modelu decyzyjnego jednocześnie. Większość firm wchodzi w tę zmianę od strony narzędzi: kupuje licencje, wdraża chmurę, zamawia system ERP. Technologia pojawia się pierwsza, bo jest namacalna, ma cenę w ofercie i termin dostawy. Zmiana kulturowa nie ma ani jednego, ani drugiego.
Badania nad transformacjami cyfrowymi, w tym prace McKinsey z przełomu lat 2018–2019, wskazują, że zdecydowana większość inicjatyw nie osiąga zakładanych celów. Liczba 70% niepowodzeń krąży od lat – i choć analitycy słusznie zwracają uwagę na problemy metodologiczne tej statystyki, sam kierunek jest bezsprzeczny: transformacje rzadko kończą się pełnym sukcesem. Standish Group w swoich raportach CHAOS od 1994 roku systematycznie pokazuje, że tylko mniejszość projektów IT dostarcza zakładane funkcje w czasie i budżecie. Reszta ląduje w kategorii challenged albo pada. Agile poprawia te liczby – projekty zwinne kończą się sukcesem kilkukrotnie częściej niż kaskadowe – ale żadna metodologia nie naprawia organizacji, która nie jest gotowa na zmianę.
Prawo Conwaya i Brooksa wciąż działają
Melvin Conway sformułował w 1968 roku obserwację, którą branża IT powtarza do dziś: systemy, które projektuje organizacja, odzwierciedlają jej strukturę komunikacyjną. Wyobraź sobie firmę, gdzie pion IT, pion biznesu i pion operacyjny rozmawiają ze sobą głównie przez formalne zgłoszenia i kwartalne przeglądy. Architektura systemu, który taka firma zbuduje, będzie miała trzy osobne moduły słabo zintegrowane ze sobą. Squady w ING nie były eksperymentem z Agile dla samego Agile – były próbą przełamania tej logiki przez zbudowanie interdyscyplinarnych jednostek z realną odpowiedzialnością za produkt.
Frederick Brooks w The Mythical Man-Month z 1975 roku pokazał coś komplementarnego: dodanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej, bo rośnie liczba kanałów komunikacji, a każdy nowy człowiek potrzebuje tygodni, żeby stać się produktywny. To prawo działa tak samo w transformacjach. Firmy, które w połowie programu zmiany dokupują konsultantów i tworzą nowe komitety sterujące, nie przyspieszają – generują głównie spotkania. Jeśli oglądałeś kiedyś roadmapę transformacji rozciągniętą na 18 miesięcy z 12 strumieniami prac i 40 stakeholderami w macierzy RACI, wiesz, o czym mówię.
Chaos Engineering zamiast udawania niezawodności
Netflix od lat stosuje podejście, które z zewnątrz wygląda jak sabotaż własnej infrastruktury. Narzędzie Chaos Monkey losowo wyłącza instancje produkcyjne, żeby sprawdzić, jak system zachowuje się pod awarią. Filozofia stojąca za tym podejściem jest prosta: skoro awaria i tak nastąpi, lepiej ją wywołać samemu, w kontrolowanych warunkach, niż odkryć ją w piątek wieczorem przy pełnym obciążeniu. To podejście wymaga jednak kultury organizacyjnej, w której inżynier nie boi się, że awaria skończy się eskalacją do zarządu i szukaniem winnych.
Sprawdź, jak wygląda postmortem po incydencie w twoim zespole. Jeśli raport koncentruje się na tym, kto zawinił, a nie na tym, co w systemie lub procesie na to pozwoliło, masz do czynienia z kulturą, która blokuje transformację niezależnie od tego, ile nowych narzędzi kupisześ. DevOps jako praktyka zakłada psychologiczne bezpieczeństwo jako warunek konieczny – nie jako miły dodatek.
Kiedy Scrum nie wystarcza – i co z tym zrobić
Wyobraź sobie startup z 12 osobami, który po rundzie finansowania zatrudnił konsultantów i wdrożył PRINCE2. Powstała dokumentacja na 200 stron, komitet sterujący zbierający się co dwa tygodnie i Business Case z projekcjami na 3 lata. Nikt nigdy nie otworzył tych dokumentów po kickoffie. Projekt dostarczył produkt – z poślizgiem 4 miesięcy i połową zakresu. Awantura była i tak.
Scrum Guide w wersji z 2020 roku jest dokumentem liczącym 13 stron. Opisuje ramy, nie przepis. Trzy role, pięć zdarzeń, trzy artefakty. Problem polega na tym, że organizacje często wdrażają Scrum ceremonialnie: Sprint Planning trwa 4 godziny, bo tak mówi podręcznik, Retrospekcja kończy się listą 12 działań, z których nikt nie rozlicza się za dwa tygodnie. Jeśli chcesz zobaczyć, czy transformacja agile w twoim dziale naprawdę działa, zajrzyj do backloga sprzed 6 miesięcy i policz, ile ticketów z tamtego okresu nigdy nie zostało zamkniętych. To lepszy wskaźnik niż velocity.
Więcej konkretnych przykładów transformacji, które przyniosły zaskakujące efekty, znajdziesz w tekście Transformacja cyfrowa: Przykłady, które zmienią twoją perspektywę.
Co decyduje o tym, że zmiana zostaje
Badania nad czynnikami sukcesu transformacji cyfrowej wskazują na kilka obszarów, które wracają niezależnie od branży:
- zaangażowanie liderów, którzy rozumieją zmianę i aktywnie ją modelują – nie delegują jej do działu IT;
- zdolność do szybkiego podejmowania decyzji na poziomie zespołu, bez wielotygodniowych ścieżek akceptacji;
- inwestycja w kompetencje ludzi, nie tylko w licencje na narzędzia;
- kultura, która traktuje błąd jako sygnał do nauki, a nie jako powód do szukania winnego.
Prawo Hofstadtera mówi, że wszystko trwa dłużej niż myślisz, nawet gdy weźmiesz pod uwagę prawo Hofstadtera. W transformacjach cyfrowych to prawo działa podwójnie. Firmy planują 18 miesięcy, kończą po 3 latach i i tak mają wrażenie, że są w połowie drogi. Pytanie nie brzmi więc, czy twoja transformacja potrwa dłużej niż zakładasz – bo potrwa. Pytanie brzmi, czy po tych 3 latach twoje zespoły będą pracować inaczej, czy tylko na innych narzędziach.
Źródła
- Conway M.E., “How Do Committees Invent?”, Datamation, 1968.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Standish Group, CHAOS Report, standishgroup.com (edycje cykliczne od 1994).
- McKinsey, “Unlocking success in digital transformations”, 2018.
- ING, “Squads, sprints and stand-ups”, ing.com, 2020.
- Spotify Engineering, “Spotify Engineering Culture”, engineering.atspotify.com, 2014.
Zdjęcie: geralt / Pixabay
