„Skoro nie zadziałało to w małej skali, to spróbujmy zrobić dokładnie to samo w dużej. Może pomoże nam efekt skali?” A może skończy się to gigantyczną katastrofą? Niestety, bardzo często skalowanie agile przebiega dokładnie w ten sposób. „Mamy w jednym projekcie Scruma, który średnio działa, ale jak wdrożymy go w całej firmie to na pewno będzie lepiej.”
Skalowanie agile – przypowieść o bieganiu
No dobrze, skoro ma być „przypowieść”, to zanim zaczniemy znęcać się nad skalowaniem agile, zajmijmy się czymś zupełnie abstrakcyjnym. Na przykład bieganiem.
Weźmy na tapetę naszego bezimiennego bohatera, który postanowił przebiec maraton. Co prawda nie do końca wie, jak się za to zabrać, ale po pierwsze – cel jest odległy, a po drugie – nie ma żadnego problemu ze znalezieniem porad w Internecie. Zaczyna więc biegać. Na początku krótkie dystanse, w wolnym tempie, tak jak należy. Mierzy swoje siły w krótszych biegach typu 10 kilometrów czy półmaraton, ale nie jest nawet w stanie przebiec całego dystansu w założonym tempie.
Niezrażony postanawia poradzić sobie z problemem w najbardziej oczywisty sposób – zwiększając intensywność treningów. Skoro lekkie treningi nie podziałały, to należy zwiększyć ich stopień trudności i częstotliwość! Zamiast biegać dwa razy w tygodniu, zaczyna to robić cztery i nawet pięć. Zamiast wolnego tempa zaczyna biegać szybko. Pal sześć częstsze kontuzje, przecież patrząc na statystyki w ulubionej aplikacji do biegania widać, że „się dzieje.”
Gdzieś w tym momencie nasz bohater postanawia też, że jego cel był za mało ambitny i zamiast tego przerzuca się na ultramaraton. Co prawda jeszcze nie udało mu się ukończyć żadnego maratonu, ale wraz z „lepszym” treningiem, powinno udać się osiągnąć więcej, nieprawdaż?
Nie jest to idealna analogia, ale przy jej użyciu chcę pokazać dwie rzeczy. Po pierwsze, jeżeli nie mamy w czymś wyników, to skalowanie (robienie więcej, szerzej) nigdy nie jest dobrym pomysłem. Po drugie, robiąc więcej, ale w dokładnie ten sam sposób trudno jest poprawić swoje rezultaty. Za zmianą ilościową musi iść zmiana jakościowa. Bo w tym wymyślonym przykładzie może wcale nie chodzić o treningi, ale na przykład o dietę.
Wróćmy jednak do tematu i zobaczmy jak się ma skalowanie agile do tego całego biegania bez sensu.
Zamki z piasku
Popełniliśmy cały wpis na temat transformacji agile, mamy też w naszej stałej ofercie szkolenie pod tytułem „Skalowanie Scrum” oraz możliwość wynajęcia nas w roli agile’owych konsultantów. Promujemy rozsądne podejście do „tej całej zwinności” i staramy się, żeby doświadczenia wszystkich były jak najbardziej pozytywne.
Ze zdumieniem obserwujemy sytuacje, w których ktoś chce rozszerzyć scrumowe podejście na całą firmę czy dział, chociaż nie mamy nawet pewności, że ono w ogóle się sprawdza. Bo to nie jest przecież tak, że wystarczy mianować Product Ownera i Scrum Mastera i już, wszystko hula. O wiele ważniejsze niż narzędzia i techniki jest samo podejście i sposób myślenia.
Jeżeli PO to taki Project Manager tylko z inną nazwą, a Scrum Master to kierownik, a zamiast wymagań mamy zadania, to nie ma mowy, żeby takie rozwiązanie a) działało b) dało się wyskalować.
Skalowanie agile to wyzwanie, które samo w sobie niesie wiele problemów. Jeżeli poszczególne projekty bądź zespoły są, delikatnie mówiąc, średnio agile’owe, to nie powinniśmy używać ich jako fundamentów dla zwinnej firmy. Będzie to przypominało budowanie zamków z piasku. Przez jakiś czas będziemy w stanie dokładać kolejne elementy, ale warunki atmosferyczne, upływający czas i skala przedsięwzięcia w końcu zrobią swoje. Wszystko się rozsypie.
Jeszcze gorzej może być tylko, gdy ktoś widząc „skalowanie agile” słyszy „wprowadźmy model Spotify w całej firmie” albo „wynajmijmy konsultantów, którzy wdrożą nam SAFe’a”.
Skalowanie agile w trybie Big Bang
Nie wiem skąd, ale bardzo często firmy upierają się na globalną, powszechną transformację, która ma od razu objąć wszystkich pracowników – od sprzątaczki, po prezesa. Taka sytuacja jest jeszcze gorsza niż naszego biegacza. Ten przynajmniej ruszył się z domu i czegoś spróbował. W przypadku podejścia „wszystko albo nic” rzucamy się na zmiany, które nie wiemy jak się skończą. Ba, nie wiemy nawet jak się zaczną!
Jest to sprzeczne z ideą empiryzmu i zwinnego eksperymentowania. Przeprowadzajmy kontrolowane doświadczenia, które w razie niepowodzenia nie wyjdą nam bokiem. Róbmy je w taki sposób, żeby się dużo nauczyć, wyciągnąć wnioski i kolejne iteracje przeprowadzać bogatsi o nowe doświadczenia. „Big bang” to przeważnie tylko dużo hałasu i sprzątania.
Zawsze, kiedy mamy do czynienia z już istniejącą organizacją, mamy też jakiś bagaż. Są doświadczenia, procedury, przyzwyczajenia, nawyki oraz cały układ sił, który niekoniecznie musi chcieć czegoś nowego. I za każdym razem należy spojrzeć na taki organizm indywidualnie i znaleźć miejsce, w którym można zacząć.
Próba dokonania wielkiego przewrotu jednym ruchem to już nawet nie jest budowanie zamków z piasku, tylko z makaronu. Ugotowanego.
Poprawne skalowanie agile
Najważniejsze słowo to „skalowanie”, które w naszym kontekście znaczy „zwiększanie rozmiaru/zasięgu.” To jest proces, który nie jest zero-jedynkowy. Nigdy z jednego zwinnego projektu nie przejdziemy od razu do agile’owej firmy zatrudniającej tysiące osób. To się musi dziać etapami, bo w parze ze zmianami procesowymi i narzędziowymi, idą zmiany w nastawieniu. A przejście od waterfallowego myślenia do agile mindsetu zajmuje o wiele więcej czasu, niż wprowadzenie do Scrum i wdrożenie Jiry.
Do całego tego procesu trzeba podejść zarówno sprytnie, jak i zwinnie. Nie ma co się porywać z motyką na słońce. Tak samo nie ma sensu schodząc pierwszy raz z kanapy i wkładając buty do biegania od razu atakować ultramaraton. Przede wszystkim najpierw zróbmy coś dobrze. Cokolwiek. Dla niektórych jeden Zespół Scrumowy działający „podręcznikowo” i regularnie wdrażający wartościowy Inkrement to za mało. Dla mnie to świetny początek udanego skalowania.
Oczywiście, nie musimy wcale zaczynać od tylko jednego zespołu. Równie dobrze może to być projekt, dział, departament, pion czy dowolna inna komórka organizacyjna. Ważne jednak jest aby móc ją wskazać i powiedzieć „tak wygląda modelowe działanie i chcielibyśmy, żeby tak wyglądało wszędzie”.
Wychodząc od czegoś, co działa, skalowanie agile staje się kwestią organizacyjną. Zadamy wtedy pytania o to, kto powinien być następny. Interesujemy się tym, jak wdrożyć i uruchomić kolejne zwinne zespoły. Która część biznesu jest najbardziej otwarta na zmiany i gdzie nam będzie najłatwiej się wyskalować.
A jak już dojdziemy do sytuacji, w której większość organizacji działa zwinnie i wszyscy wiedzą, że wychodzi im to na dobre, to nie będziemy mieli problemu z brakiem chętnych albo z ostatnimi bastionami „starego podejścia”.
Skalowanie agile nie jest wcale takie straszne! Czekamy na Wasze pytania i wyzwania zarówno w komentarzach, jak i bezpośrednio przez formularz kontaktowy i telefon.
Porównanie do biegacza mi nie pasuje do tego kontekstu. Miałoby sens gdybyśmy mówili o skalowaniu rozwiązania wypracowanego przez jeden zespół, skalowaniu produktu, ale w przypadku skalowania agile dla zarządzania przedsiębiorstwem to coś innego.
Zwinność biznesową bardziej należy porównać np. do organizacji zawodów sportowych, gdzie występują zespoły sportowe w danych dyscyplinach (lepsze lub gorsze). A teraz chcemy zorganizować zawody w określony sposób dla wielu zespołów. Potrzebujemy spójnych zasad, jasno wyznaczonych ram. Zespoły mogą poruszać się w tej samej dziedzinie (np. piłka nożna – powiedzmy Scrum), ale mogą też w różnych (np. piłka nożna, siatkówka – XP, hokej – Kanban), jak na olimpiadzie. Podobnie jak na olimpiadzie, są jeszcze sędziowie – np management, którzy też mogą się kierować osobnymi wymaganiami (np. Beyond Budgeting).
Skalowanie Agile dla biznesu to proces tworzenia tych wspólnych ram, która umożliwi tym zespołom współdziałanie.
Porównanie do biegacza miało pokazać bezsens podejścia pod tytułem „co prawda jeszcze nie wiem, czy to działa, ale chcę to zrobić w większej skali.” A to akurat występuje na każdym szczeblu.