A na tegorocznej Agile by Example pojawił się taki slajd:

Spotify opublikowało swój koncept na trajby i skłody w 2012 r., model leadershipu w 2014 r. Uważasz, że po niemal ośmiu latach to wciąż aktualne?

Co się zmieniło?

Struktura Spotify ewoluowała przez ten czas, a załączony slajd i rozmowy po prezentacji mówią min., że:

  • Zamiast organizacyjnego Chapter Leada mamy Engineering Managera z technicznym skilem
  • Zamiast 160 agile coaches na 160 zespołów mamy ich 40 :)

Kult cargo

Mianem kultu kargo community developerskie nazywa bezrefleksyjne stosowanie jakiegoś podejścia do architektury, bo np. tak robią Google i Neflix. Zazwyczaj końcowy efekt jest taki, jak na poniższym filmie.

https://www.youtube.com/watch?v=2j--olxjpwM

Wdrażanie AS IS modelu Spotify czy innego agile@scale, to właśnie kult cargo. Prawie na pewno się nie uda.

Cała prawda o agile@scale

Jeśli weźmiesz Scruma albo Kanbana w ich definicyjnej formie, to raczej będzie to miało ręce i nogi. Złożoność wdrożenia w pojedynczym zespole jest do ogarnięcia. Takie wdrożenie jest deterministycznie powtarzalne.

Z agile@scale jest inaczej. Jest na to parę pomysłów: Spotify model, SAFe, LeSS, DAD, Nexus i coś tam. Jednocześnie nie ma powtarzalnej metody na skalowanie zwinności. Są przypadki organizacji, którym się udało oraz cała lista tych, którym się nie udało. Przypadki są, ale powtarzalności nie ma.

Moim zdaniem nigdy tej powtarzalności nie będzie. Why? Jestem śmiertelnym wrogiem naukowych metafor do życiowych problemów, ale ten jeden raz się złamię. Zasadę Heisenberga pewnie pamiętasz: nie można z tą samą dokładnością zmierzyć jednocześnie pędu i położenia cząstki, bo sam pomiar wprowadza zaburzenie. Tunigowanie narzędzi pomiarowych niczego nie zmieni, gdyż taka jest natura rzeczy. Nie da się i już.

Zasada nieskalowalności Bartyzela

Z agile@scale jest analogicznie. W kontekście większym niż jeden zespół, materializuje się nowa nieznana uprzednio zmienna: złożoność. I gdy próbujesz wdrożyć jeden słuszny model, złożoność wywala ci skalowanie w kosmos.

Na czym oprzeć skalowanie?

Moim zdaniem osią skalowania muszą być wartości wpisane w zwinność. Nie chodzi o rozmyte pojęcie "wartości" z internetów, tylko o coś bardzo bardzo konkretnego.

Krótko przypomnę, o czym jest zwinność oraz jej z historyczne tło.

Nurt agile jest osadzony na kanwie psychologi humanistycznej Carla Rogersa. Oznacza to, że przyjmujemy, iż człowiek jest podmiotem sam sobie i każdy wnosi do ogółu coś ważnego i unikalnego.

Nie jest również tajemnicą, że Gerald Weinberg - inżynier IT i psycholog wraz z Virginią Satir - twórczynią podejścia systemowego w terapii rodzin, współpracowali na psychologicznymi aspektami procesów wytwarzania oprogramowania. W niektórych kręgach Satir nazywana jest "agile goddess". Efektem współpracy było coś, co obecnie nazywamy "system thinking".

Następnie do gry weszli inżynierowie min.: Kent Beck, Ward Cunningham, Martin Fowler, Bob Martin, Alistar Cockburn i podpisali przesławne #agileManifesto, gdzie podkreślili, że cel developmentu - czyli soft - ma prymat nad wszystkim innym. Opisałem to nieco szczegółowiej w Czy to jest agileowe?.

Pamiętajmy jednak, że cała praca, inżynieria, metody i frameworki zanużone są, niczym w eterze, w psychologii humanistycznej, która przyjmuje a priori, że człowiek jako całość-osoba jest podmiotem działania, a nie tylko jego poszczególne atrybuty, czy zachowania.

I to jest właśnie to, co w nurcie agile rozumie się jako WARTOŚĆ. Z tej WARTOŚCI biorą się pochodne: komunikacja, współpraca, zaufanie, individuals and interactions itd.

Top-down-bottom-up-top-down-bottom-up

Skalowanie top-down, czy bottom-up? I tak, i tak - na zamianę. Management board daje przyzwolenie, możliwości i kierunek. Inicjatywa operacyjna musi iść bottom-up. Bez wsparcia zarządu oddolna zmiana się zadusi. Bez early adopters po stronie specjalistów zwinność stanie się tylko kolejnym procesem na ładnym obrazku.

Organizacja może zacząć od wdrożenia Scruma tu i tam, ale w skalowaniu musi, krok po kroku, znaleźć własną strukturę i procesy.

Manager w IT

Jeśli już zdążyłeś zwolnić wszystkich managerów IT, bo "samoogranizacja", a w ogóle to w ScrumGuide ich nie ma, to lepiej szykuj bonusy, żeby wybłagać powrót.

Mój pogląd na rolę managera IT opisałem w Blady strach padł na managerów.

Manager IT:

  • „dostarcza zespoły, które dostarczają wartość”
  • ma +10 do respektu na open-space za skill techniczny
  • wspiera ludzi na ich ścieżkach karier
  • jest gwarantem bezpieczeństwa inwestycji dla inwestorów i akcjonariuszy
  • wespół z innymi managerami IT odpowiada za stworzenie ekosystemu organizacyjnego, w którym zespoły będą mogły pracować efektywnie; a w tym się mieści odpowiedzialność za architekturę korporacyjną - o tak :)
  • krzewi kulturę pracy i etosu inżyniera

A jak tam z architekturą?

Do identycznych mieszkań w stanie developerskim weszły 2 ekipy:

  • pierwsza stawia ściany działowe z cegły, a zasilanie wodą prowadzi w rurach ocynk
  • druga stawia ściany działowe z karton-gipsu, a wodę ogarnia rurami plastikowymi i zgrzwarką

Która wcześniej odda mieszkanie inwestorowi i szybciej zareaguje na zmiany? Albo po naszemu: która jest bardziej zwinna?

Druga, bo stosowane przez nią architektura ścian, rur oraz narzędzia pozwalają jej na zwinność.

I teraz zapytaj sam siebie, nie odpowiadaj na głos tylko takim wewnętrznym niemym krzykiem:

  • jeśli twój soft to monolit,
  • jeśli tak naprawdę wdrażasz się raz w roku,
  • jeśli jedyną formą testowania są testy manualne,
  • jeśli paczki wdrożeniowe lecą do release managera mailem w zipie,
  • jeśli robisz CQRS, bo tak było na konferencji,
  • jeśli masz fragmenty kodu o CC>100 i każdy boi się tego dotykać,
  • jeśli przychodzisz do pracy na 5.30 bo liczba licencji na IDE jest ograniczona,
  • jeśli na retro ważne jest tylko jakim kolorem był twój sprint,

to w jaki konkretny sposób chciałbyś być zwinny?

Z tym pytaniem cię zostawiam.

Ciekawe artykuły temacie

.