Pierwsza zasada skalowania zwinności, nie skaluj

Punkty widzenia

Pierwsza zasada skalowania zwinności, nie skaluj

Zwinne Organizacje | Podcast o agile | odc. 47

Porozmawiamy o dobrych praktykach i wyzwaniach skalowania.

Paweł Tomkiel
W dzisiejszym odcinku chcę poruszyć temat, który już od jakiegoś czasu mam na sercu. Jest to temat skalowania zwinności. O skalowaniu rozmawialiśmy już z wieloma gośćmi w tym podcaście. Dzisiaj chce porozmawiać o tym z drugiej strony, chcę porozmawiać o tym, co się czasem gdzieś widzi. Tu odwołuje się do różnych artykułów, różnych osób związanych ze zwinnością, gdzie pierwszą zasadą skalowania zwinności jest, żeby nie skalować.

Może na początek wyjaśnię, co mam na myśli, mówiąc skalowanie. Wyobrażam sobie sytuację, gdzie mała organizacja zaczyna być zwinna. Zaczyna stosować Scrum w jeden, dwóch czy więcej zespołach i te zespoły są autonomiczne, są produktowe i działają w sposób zwinny, ale potem organizacja rośnie i ta duża organizacja nadal chce zachować zwinność. Przez skalowanie, tutaj rozumiemy, poszerzenie tych zwinnych praktyk, które się narodziły jeszcze w mniejszych zespołach, w mniejszej organizacji. Poszerzenie tych praktyk i wyskalowanie ich na całą organizację, która jest już duża, która już urosła. To niekoniecznie musi wyglądać w ten sposób, że na początku mamy małe organizacje, a potem dużą. Może to też działać tak, że w dużej organizacji, na początku jeden, kilka- dwa, czy trzy zespoły są pilotażowe. Działają w sposób zwinny i potem organizacja chce zaadoptować te praktyki, tak jak jest długa i szeroka. Więc to będzie skalowanie.

Co się dzieje, kiedy zaczynamy skalować jakiekolwiek procesy, jakiekolwiek praktyki. Przede wszystkim myślę tutaj o działaniu z produktami cyfrowymi, z wytwarzaniem jakiegoś oprogramowania, z utrzymywaniem jakichś systemów. I kiedy próbujemy w sposób zwinny podchodzić do coraz większej ilości komponentów w naszym systemie, wzrasta ilość zależności między nimi. To znaczy, jeżeli dwa zespoły pracują za sobą nad jednym produktem, to jest im łatwiej się porozumieć, łatwiej jest im zaplanować. Łatwiej jest im rozwijać ten produkt, bo on jest jeszcze mały. One są w stanie wymieniać się tymi informacjami na bieżąco. Co do tego, co się zmienia w tym systemie. Ale kiedy myślimy już o dziesięciu czy pięćdziesięciu zespołach, które pracują nad wspólnym produktem, wtedy ta ilość zależności między nimi robi się bardzo duża. Kiedy ta ilość zależności rośnie, to zależnościami można próbować zarządzać przez wykazywanie jakichś praktyk, przez wyskalowanie jakiegoś procesu albo te zależności minimalizować, ale do tego, jak skalować, przejdziemy jeszcze na końcu.

A teraz, jaki jest sedno, jaki jest problem ze skalowaniem praktyk zwinnych w dużych organizacjach. Kiedy próbujemy wyskalować praktyki zwinne, czyli praktyki szybkie, praktyki, które się szybko adaptują do zmiennych warunków, do zmiennego rynku, do zmiennych użytkowników. Te dwa wcześniej zespoły, które mogły pracować zwinnie, które mogły pracować ze sobą, mogły rozwijać ten produkt, zmieniać go, działały szybko. Ale kiedy próbujemy już to wyskalować na całą organizację, tych zespołów robi się dziesięć, pięćdziesiąt. To spowalnia proces, bo te zespoły teraz tracą dużo więcej czasu na komunikację ze sobą, na planowanie wspólne tego, co zostanie zrobione w produkcie. Pierwszy problem ze skalowaniem jest taki, że on spowalnia proces siłą rzeczy. Druga rzecz, którą widzę to to, że proces decyzyjny dotyczący produktu, który tworzymy, dotyczący jakichś komponentów, przesuwa się na szczyt. Bardzo często widziałem organizacje, w których to na samej górze organizacji były podejmowane decyzje dotyczące rozwoju produktów, no bo ten produkt był jednym powiedzmy sporym monolitem, nad którym pracowało pięćdziesiąt zespołów i potrzebna była taka centralizacja planu. Ktoś, kto powie z góry okej, to jest naszym priorytetem, tym się teraz zajmujemy przez najbliższy kwartał, rok. Tutaj nawiązuję trochę do planowania rocznego, o tym również jest odcinek. Ten proces decyzyjny przesuwa się na szczyt. Ludzie, którzy pracują w zespołach, którzy są najbliżej produktu, którzy go rozwijają, już nie decydują o tym, co zostanie zrobione i w jakiej kolejności. Jeżeli mamy bardzo zależne od siebie różne zespoły, to nie jest to do końca możliwe, żeby te zespoły mogły decydować same o swoich komponentach, same o swoich produktach i to jest ten problem, który również spowalnia i usuwa tę autonomiczność z zespołu. Czyli skalowanie w taki sposób, że proces pominie tych inżynierów, którzy są w zespołach, pominie same zespoły, pominie ich autonomiczność i przesunie ten proces decyzyjny na szczyt.

Tutaj chyba warto nawiązać do prawa Conway'a, które mówi, że produkty czy systemy tworzone przez organizacje, będą odzwierciedlały strukturę komunikacyjną w tych organizacjach. To znaczy, że jeżeli struktura organizacyjna wygląda tak, że mamy zespół frontendowy i backendowy, dwa zespoły dla uproszczenia, to system, który będzie budowany, będzie odzwierciedlał to, że powstanie komponent frontendowy i backendowy, i one będą się porozumiewały ze sobą tak dobrze, jak zespoły dochodzą do porozumienia ze sobą. Systemy będą odzwierciedleniem tego, jak zespoły ze sobą się komunikują. To idzie też dalej, bo jeżeli w firmie mamy dziesięć zespołów, które pracują nad jednym systemem i każdy jest odpowiedzialny za jedną warstwę tego systemu, to tak samo ten system będzie odzwierciedlał tą strukturą organizacyjną, którą mamy w organizacji. Prawdopodobnie będzie to dziesięciowarstwowy system, w którym każda warstwa rozmawia z każdą warstwą i tak te dziesięć zespołów dochodzi do porozumienia ze sobą. Prawo Conway'a tutaj można zastosować, żeby zrozumieć ten fakt, że jeżeli chcemy mieć szybko działający produkt, chcemy mieć produkt spójny sam w sobie to idealnie, gdyby zajmował się nim jeden zespół, znaczy jedna jednostka, która buduje ten produkt, bo ci ludzie będą w stanie podejmować 100% decyzji za ten produkt. To nie jest realne w dużych organizacjach, żeby mieć taki zespół, ale przejdziemy jeszcze do tego na koniec.

Zapraszamy do wysłuchania całego odcinka.

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Subskrybuj podcast o agile "Zwinne organizacje"

Otrzymuj powiadomienia o nowych odcinkach:
iTunes   Android   RSS   eMail   Spotify

Potrzebujesz wsparcia w swojej organizacji? Chętnie pomożemy!
Widzimy, że produkty cyfrowe można tworzyć o wiele szybciej i taniej, jeśli ludzie będą zorganizowani wokół produktów, a nie wokół wydzielonych funkcji. Wymaga to dużej zmiany, w której pomagamy naszym Klientom. Zachęcamy do kontaktu.

Czy ta strona była pomocna?