Pięć pułapek przy skalowaniu zwinności

Duże firmy szczególnie szukają szybkich i łatwych sposobów na przejście z tradycyjnego na zwinne podejście do wytwarzania. Im szybciej ma przebiegać transformacja, tym groźniejsze są pułapki, które są przeoczane. Zwinne wytwarzanie stawia bardziej na zrównoważony rozwój niż na szybkie uwinięcie się ze wszystkim. Dlatego zarządzanie ponosi ogromną odpowiedzialność za sukces zwinnej transformacji. Na zewnątrz transformacja wygląda na udaną, ale od środka korzyści z niej nie są odczuwalne.

Poniżej zebraliśmy pięć typowych pułapek na drodze do zwinnej organizacji:

1. Fundamentalna zwinność

Przejście na zwinne procesy jest łatwe. Trochę deregulacji i wysyłasz kilka osób na szkolenie. Po tym ludzie mogą „robić Scrum" – albo wybrać inne zwinne podejście. Ale patrząc na całość: może osiągnąłeś 1% – 99% drogi jest wciąż przed tobą. Podróż jest jeszcze długa. W sercu zwinności leży proces Inspect+Adapt.

Aby to działało, potrzebne jest szczególne nastawienie. Każdy musi bezlitośnie kwestionować to, co się dzieje – i wprowadzać zmiany, gdy sprawy idą w złym kierunku. Aby sensownie zakorzenić Inspect+Adapt w organizacji, potrzebne są dwie rzeczy:

Po pierwsze, istniejący sposób pracy musi zostać oczyszczony z toksyn. Elementy kultury firmy, które zniechęcają deweloperów do przejmowania odpowiedzialności za swoje procesy, muszą zostać usunięte. W tym celu wiele procesów Command+Control musi zostać wywróconych do góry nogami, a zarządzanie deweloperami musi być fundamentalnie przemyślane. Zmiana nastąpi tylko wtedy, gdy zostanie dopuszczona!

Po tym musi zostać stworzony zdrowy sposób pracy. Potrzebny jest system zarządzania, który zachęca deweloperów do brania odpowiedzialności za własne działania, decyzje, zmiany, porażki i sukcesy. Wymaga to tworzenia struktur i procesów, które uczciwie doceniają indywidualny wkład każdej osoby – niezależnie od tego, czy zarząd jest aktualnie zadowolony z kierunku, czy nie. Ludzie wniosą swój wkład tylko wtedy, gdy im się na to pozwoli!

Dopóki nie zostanie położony fundament dla zwinności, nie będzie zwinności. Zespoły bez fundamentalnej zwinności nie będą ani korzystać ze skalowania zwinności, ani do niego przyczyniać się.

2. Narzędzia i techniki

Wprowadzenie ceremonii Scruma zajmuje zaledwie jeden dzień, łącznie ze szkoleniem i decyzją. Daje to podstawę dla „zwinnej pracy". Krótkoterminowe planowanie, regularne aktualizacje planu, informacja zwrotna o produkcie i przyrostowe doskonalenie procesu są niezbędne. Z czasem deweloperzy mogą odkryć optymalny sposób pracy. Wystarczy zaplanować dużo czasu na optymalizację, jeśli praktyki inżynierskie nie są jeszcze ugruntowane. Deweloperzy muszą znać takie pojęcia jak kontrola wersji, Continuous Integration, automatyzacja testów, emergent design, TDD, BDD, pair programming, konwencje kodu – i wiele innych, co XP ma do zaoferowania. Muszą świadomie decydować, które z tych praktyk są pomocne w ich obecnym kontekście. Dopóki deweloperzy nie znają tych praktyk, mogą być „rytualistycznie zwinnymi", ale nie praktykować zwinności. Zespół bez odpowiednich narzędzi może nawet spowolnić wdrożenie skalowanego wytwarzania.

3. Duch zespołu

Duch zespołu, często wyśmiewany jako ezoteryczny, ma ogromne znaczenie dla systemowego doskonalenia przy skalowaniu zwinności. Wielu menedżerów uważa, że osobiste cele (aż po stack ranking) pomagają w zdobyciu pracowników o wysokiej wydajności. Skalowanie zwinności służy jednak przede wszystkim budowaniu złożonego, adaptacyjnego systemu, w którym wiele osób wnosi swój wkład. Konieczność wniesienia wkładu w wielką całość jest o wiele ważniejsza niż wkład we własne cele. „Duch zespołu" oznacza tutaj, że jednostki muszą zasadniczo podporządkować własne interesy dla promowania misji firmy. Duch zespołu polega mniej na „robieniu fajnych rzeczy z innymi" (np. eventy teamowe jak rafting, gokarty czy paintball). Chodzi przede wszystkim o czerpanie radości z robienia rzeczy, które pomagają posuwać się do przodu wspólnie.

Deweloperzy potrzebują do tego dwóch rzeczy: Po pierwsze, muszą wiedzieć, jak mogą wnosić wkład. Ponieważ zależy to bardzo mocno od indywidualnego przypadku, wkład rodzi się przede wszystkim z samoorganizacji i wewnętrznej motywacji. Po drugie, muszą wiedzieć, że pomocność się opłaca. Wszystko, co stwarza osobistą niekorzystną sytuację, gdy pomaga się innym w osiąganiu wspólnego celu, musi zostać usunięte. Klasycznym przykładem „ducha zespołu" jest piłka nożna: często widzieliśmy, że meczu nie wygrywa najlepszy zawodnik. Wygrywający jest najlepsza drużyna. To samo dotyczy wytwarzania: asy, które wzajemnie się prześcigają, nie wygrywają. Wygrywa się przez łączenie sił, skupianie pomysłów i wspólne posuwanie się do przodu.

Grupy deweloperów bez ducha zespołu trwonią energię na „zajętość". Skalowana grupa, która nie jest zespołem, wykorzystuje tylko ułamek swojego potencjału do osiągnięcia wspólnego celu!

4. Przejrzystość

Wiele organizacji ponosi porażkę z powodu braku wiedzy o całym systemie. Nie mogą globalnie optymalizować. Klasyczne przeszkody dla przejrzystości istnieją na wszystkich poziomach: od dewelopera, który nie wie, jak praca kolegi na niego wpływa, po menedżera, który nie potrafi powiedzieć, co jest absolutnym priorytetem 1. Ten brak przejrzystości prowadzi do wielu problemów. Zaczyna się od dewelopera, który nieświadomie torpeduje pracę swoich kolegów, a kończy na całych zespołach pracujących nad złymi rzeczami. Nic z tego nie jest pożądane, i im częściej coś takiego się zdarza, tym bardziej krytyczne i ważne jest zwiększenie przejrzystości.

Niektóre organizacje trwonią niemal całą pojemność na zarządzanie problemami spowodowanymi brakiem przejrzystości. W takich sytuacjach „harówka" jest chyba trafniejszym opisem niż „skalowanie". Istnieje wiele dźwigni do zwiększenia przejrzystości na tyle, by skalowanie miało sens. Oto kilka z nich:

• Uruchom Kanban – który każdy może zobaczyć!

• Centralny Backlog, z którego korzystają wszystkie zespoły

• Collective Code Ownership jako podstawa komunikacji przez kod

• Andony: Build Monitoring i „Stop the Line" oparte na zautomatyzowanych testach

• Wspólne planowanie i wspólne przeglądy, na których pokazywany jest tylko zintegrowany produkt

Przejrzystość jest odwrotnie proporcjonalna do nadmiaru i problemów. Innymi słowy: przy skalowaniu zwinności przejrzystość jest proporcjonalna do ROI. Zwinne zespoły pozbawione przejrzystości nie wnoszą sensownego wkładu w cele biznesowe.

5. Fokus

W wielu organizacjach jednym z głównych problemów jest błędne skupienie na obciążeniu: zarządza się pracą i przynosi zadania pracownikom. Podstawowe założenie jest tutaj takie, że wartość tworzy się przez maksymalne „zajęcie" wszystkich. W zwinnej organizacji jest odwrotnie: przynosimy ludzi do pracy, która jest warta wykonania. Wiemy, że nie ma pozytywnego powiązania między tworzeniem wartości a obciążeniem. Skupiamy się na dostarczaniu użytecznego produktu – na ukańczaniu rzeczy. Klasycznym problemem w wielu organizacjach jest to, że przez próby obciążania pracowników, wiele rzeczy jest „w toku": Wymaga to przełączania kontekstu i koordynacji. Ale nawet w najbardziej banalnych scenariuszach wynikająca z tego utrata fokusu prowadzi do drastycznie zmniejszonego ROI i znacznie wydłużonego czasu realizacji: Spędzamy zbyt dużo czasu na próbach ustalenia, dlaczego nic nie jest ukończone – a za mało na próbach ukończenia czegokolwiek.

Główna idea skupienia jest następująca: Robienie złej rzeczy najpierw, a dopiero potem właściwej, kosztuje o wiele mniej niż robienie dwóch rzeczy jednocześnie. Choć brzmi to trywialnie, jest trudne do wdrożenia: Cała organizacja potrzebuje jasno posortowanej listy celów, a każdy cel musi być jednoznacznie spriorytetyzowany. Jest dokładnie jeden, jedyny Priorytet 1. Następnie Work in Progress musi być ściśle ograniczone. Fokus wymaga od menedżerów fundamentalnego przemyślenia ich podejścia: trzeba zaakceptować, że „przestój" kosztuje mniej niż przeciążenie. Nie można też dostać wszystkiego jednocześnie. Nieskupione zespoły mogą być „dobrze obciążone", ale są wysoce nieefektywne. Im mniej skoncentrowane, tym dłużej zajmuje im tworzenie wartości.

Pułapki przy skalowaniu zwinności

„Skalowanie zwinności", które nie dba o wymienione wyżej pułapki, najprawdopodobniej skończy się jako kult cargo. Na zewnątrz transformacja wygląda na udaną, ale od środka korzyści z niej nie są odczuwalne. W przypadku udanych zwinnych transformacji powszechnym podejściem jest sprowadzenie na pokład doświadczonych ekspertów, którzy „walczyli na froncie" i znają pułapki.
Aby ominąć pułapki w środowisku skalowanym, zalecamy:

• Wsparcie zarządzania dla transformacji. Aby zamknąć pułapki, niektóre rzeczy w organizacji muszą zostać wywrócone do góry nogami. Wymaga to pełnego wsparcia ze strony zarządzania.

• Zbuduj Agile Transition Team (ATT), w którym uczestniczą zarówno menedżerowie, jak i deweloperzy. ATT ma jasny Backlog zmian, nad którym wszyscy wspólnie pracują.

• Executive Coaching dla kluczowych osób transformacji. Obejmuje to menedżerów liniowych, Product Ownerów i Scrum Masterów. Zewnętrzny coach musi mieć doświadczenie w skalowaniu zwinności!

• Coaching techniczny pomaga zespołom szybciej zdobyć odpowiednie narzędzia: Szybko się to opłaca dzięki produktowi wyższej jakości!

• Zatrudnij konsultanta do kierowania transformacją. Ta osoba musi dokładnie wiedzieć, co robi i musi pracować bez kompromisów. Musi mieć uprawnienia do przeprowadzania nawet niepopularnych zmian.

• Szkolenie dla wszystkich w zakresie zwinności. W bezpiecznym środowisku szkoleniowym wpływ transformacji jest znacznie łatwiejszy do przekazania.