O dwóch podejściach do skalowania zwinności w organizacji.
Duży może więcej. Wiadomo. Kolosy jednak mają to do siebie, że choć potężne, to bywają zazwyczaj ślamazarne. Reagują z opóźnieniem, czasem zbyt późno. Jak zwiększyć swój potencjał nie tracąc zdolności szybkiego reagowania na zmiany otoczenia? To proste – trzeba być i dużym, i zwinnym.
Czym jest Agile?
Jest spora szansa, że jeśli wyszukałeś artykuł na temat skalowania zwinności, to co najmniej orientujesz się czym jest Agile, ale jeśli nie, to wiedz, że Agile to:
podejście do realizacji projektów (mimo popularyzacji wciąż jeszcze głównie informatycznych), według której większą wartość dostrzega się w budowaniu mechanizmów szybkiego dostosowania się do zmian w projekcie i jego otoczeniu oraz elastycznego reagowania na bieżące potrzeby, niż w dążeniu do zdefiniowania, z dużą dokładnością, podstawowych parametrów projektu (cel, zakres, budżet, czas realizacji) już przy jego uruchomieniu.
Trochę więcej o różnicy między klasycznym i zwinnym podejściem do realizacji projektów znajdziesz tutaj:
czytaj więcej …
AGILE CZYLI WATERFALL DO GÓRY NOGAMI
Nieco upraszczając, przesłanie Agile jest następujące:
nie zastanawiaj się przesadnie, nie planuj projektu od A do Z, bo nie warto, oszacuj, wykonaj prototyp, wyciągaj wnioski z obserwacji działającego produktu i procesu, przygotuj następnie pierwszą wersję produkcyjną, daj użytkownikom i udoskonalaj produkt słuchając informacji zwrotnych, rozwijaj go płynnie, relatywnie małymi lecz częstymi przyrostami funkcjonalności.
Podstawy zwinnych metod realizacji projektów opisuje Manifest Agile. Nawet jeśli znasz już konkretne frameworki Agile, to warto czasem wrócić myślami do źródła, żeby nie zagubić idei.
Warto być zwinnym
Korzyści ze stosowania zwinnych metod realizacji projektów jest wiele, oczywiście w środowiskach, a których podejście zwinne jest zasadne, poniżej znajdziesz te, które najłatwiej dostrzec:
projekty uruchamiane są dużo szybciej niż w podejściu klasycznym – okres analizy wstępnej jest krótszy, nie staramy się zaplanować projektów od A do Z, dzięki czemu nie tracimy długich miesięcy, a nawet lat, na definiowanie wymagań, analizy, projektowanie, czy kontraktowanie podwykonawców
najszybciej jak to jest możliwe wypracowujemy w projekcie działające rozwiązanie i weryfikujemy nasze plany w oparciu o realny feedback od użytkowników, zamiast bazować na naszych wyobrażeniach i prognozach
zazwyczaj dużo szybciej niż w projektach klasycznych wdrażamy rozwiązanie (choć zakres pierwszego wydania jest relatywnie mały) i zaczynamy czerpać z niego korzyści
Dobrze jest też być dużym
Małymi krokami nie przeskoczysz przepaści. Zdarza się że nawet minimalny zakres produktu, z jakim wychodzimy do użytkownika musi być relatywnie duży, zdarza się że bardzo zależy nam na czasie lub poziom skomplikowania dostarczanego rozwiązania wymaga wielu różnorodnych kompetencji. Wtedy angażujemy wielu zespołów, kupujemy usługi spoza organizacji, integrujemy z naszym rozwiązaniem gotowe komponenty, bądź całe systemy. Z czasem od tego, co dzieje się wewnątrz zespołu większym wyzwaniem stają się interakcje pomiędzy zespołami agile’owymi. Wtedy frameworki agile znane do tej pory przestają mieć zastosowanie, choć wciąż zasadne pozostają pryncypia Agile Manifesto.
Chcesz się rozwijać nie zatracając swojej zwinności – skaluj ją
Najbardziej popularne metody skalowania Agile, to:
LeSS (Large Scale Scrum)
Nexus
Scrum at Scale
SAFe (Scaled Agile Framework)
Trzy pierwsze opisują jak radzić sobie z dużą ilością deweloperów i stosować na poziomie zarządzania grupą zespołów mechanizmy, które działały w pojedynczych zespołach. W dużej mierze koncentrują się na organizacji pracy zespołów zwinnych kładąc nacisk na integrację rozwiązań, a czasami nawet dedykując do tego osobny zespół (np. Integration Team w przypadku Nexusa). Ich mocną stroną jest przede wszystkim mocna spójność ze znanym powszechnie Scrumem i możliwość szybkiej implementacji, co jest szczególnie cenne w środowiskach, w których objęte nimi zespoły posiadają dużą autonomię i są mocno wydzielonym obszarem.
SAFe podchodzi do tematu skalowania znacznie szerzej, przez co uważany jest za zbytnio rozbudowany i zbyt ciężki jak na framework agile’owy, a w związku z tym zarzuca mu się zatracanie zwinności. Jego intencją jest rozprzestrzenienie zasad Lean i Agile w całej organizacji na wszystkich jej poziomach zarządczych i we wszystkich obszarach dziedzinowych. W tak rozumianym środowisku, Agile obejmuje nie tylko techniki wytwarzania oraz role i procesy zarządzania grupami zespołów, ale także między innymi:
Zapraszamy na szkolenie
Szkolenia SAFe
- zarządzanie produktami (w wymiarze cech funkcjonalnych jak i generowanej wartości biznesowej) od strategii organizacji poprzez strumienie wartości, wizje produktów, roadmapy ich rozwoju, programy wprowadzające milowe przyrosty funkcjonalności rozwiązań po pojedyncze historie użytkownika przetwarzane przez zespoły w działające rozwiązania
- zarządzanie architekturą dostarczającą komponenty technologiczne stanowiące szkielet, wokół którego zespoły deweloperskie przetwarzają wymagania biznesowe w działające rozwiązania, poruszając się swobodnie w ramach nakreślonych przez architektów i wspólnie uzgodnionych przez zespoły
- zarządzanie inicjatywami strategicznymi od motywów strategicznych poprzez poziom portfela programów, a następnie same programy do działań operacyjnych realizowanych przez zespoły zwinne, przy zachowaniu spójności rozwiązań z wizją biznesową, a jednocześnie przy zagwarantowaniu swobody podejmowania decyzji odnośnie priorytetów prac, na każdym poziomie zarządczym
- budżetowanie, gdzie finansowane są całe strumienie wartości dostarczające przyrosty w sposób zwinny, a nie pojedyncze inicjatywy o zdefiniowanych z góry zakresach i terminach realizacji
- zagadnienia HRowe dotyczące motywacji pracowników, efektywności ich pracy i przestrzeni do rozwoju
Skalowanie Agile jest bardzo złożonym zagadnieniem, bo odnosi się do dużej ilości specjalistów zaangażowanych w realizację projektów i całych organizacji, jest czymś znacznie więcej niż sposobem organizacji pracy zespołów deweloperskich. Może ograniczać się do oczywistych mechanizmów w stylu:
- mamy paru Scrum Masterów więc przydałby się ktoś, kto koordynuje ich dbając o procesy na poziomie całych programów
- mamy wiele zespołów deweloperskich, więc ktoś musi przygotować wizję architektury i współdzielone komponenty oraz wyznaczyć ramy i standardy pracy zespołów (w tym zakres samodzielności)
- mamy dema przyrostów zespołów, więc przydałoby się również raz na jakiś czas demo przyrostu całego zintegrowanego rozwiązania
potrzebujemy jednego współdzielonego backlogu całości systemy i osób, które koordynują pracą Product Ownerów
… itd.
Możemy też od razu myśleć o całej organizacji, o tym co dzieje się przed uruchamianiem projektów zwinnych i tym co dzieje się po ich zakańczaniu. O tym w jaki sposób organizować strategię rozwoju produktów, żeby móc zwinnie realizować poszczególne przyrosty. Możemy wprowadzać filozofię i mechanizmy regulujące współpracę zespołów technologicznych z pozostałymi obszarami organizacji, w tym z podwykonawcami i klientami. Możemy dbać o to, żeby polityka HR firmy i jej kultura organizacyjna wspierały zwinność zespołów poprzez budowanie ich samodzielności.
Która pigułka?
Które podejście jest lepsze? Może oba, może żadne. To zależy w dużej mierze od dojrzałości organizacji i tego jak dużą swobodę mają na co dzień zespoły agile’owe. Duży wpływ ma też to, jak bardzo ich praca jest uzależniona od pozostałych obszarów organizacji. Patrząc na to, jak marginalnie jest często postrzegany agile w dużych organizacjach, dla wielu z nich można by sparafrazować scenę z Matrixa, w której Morpheus daje Neo dwie pigułki – jeśli wybierzesz niebieską, pójdziesz łatwą ścieżką i dalej będziesz żył w bajce, w której agile jest ładnym hasłem do realizacji wybranych etapów projektów waterfall’owych i większości nie będzie to przeszkadzało, jeśli wybierzesz czerwoną to zobaczysz jak ciężką pracę trzeba włożyć, aby zwinna stała się cała organizacja (bądź jej spore obszary), ile murów trzeba rozbić, ile betonu trzeba przewiercić, ile szklanych sufitów będzie musiało popękać, ale efekt powinien być tego wszystkiego wart.
Użyta grafika pochodzi z ptmoney.com.
