Scaled Agile Framework i jakość

SAFe jest jednym z najpopularniejszych frameworków, które starają się rozwiązać problemy skalowania projektów składających się z więcej niż jednego zespołu. Co ważne jest udostępniany bezpłatnie przez firmę Scaled Agile, Inc., która zachowuje dla siebie prawa autorskie i znaki towarowe.

10 podstawowych zasad SAFe 

Wywodzą się one z istniejących zasad lean oraz zwinnych, a także obserwacji autorów frameworka: 

1. Przyjmij ekonomiczny punkt widzenia.
2. Zastosuj myślenie systemowe.
3. Załóż zmienność; zachowaj różne opcje.
4. Buduj przyrostowo z szybkimi cyklami uczenia.
5. Definiuj kamienie milowe na obiektywnej ocenie działania systemów.
6. Wizualizuj i ograniczaj prace w toku (ang. work-in-progress), zmniejsz rozmiary paczek i zarządzaj długościami kolejek.
7. Zastosuj kadencję (czasowość), synchronizuj się z planowaniem międzydomenowym.
8. Odblokuj wewnętrzną motywację pracowników merytorycznych.
9. Zdecentralizuj podejmowanie decyzji.
10. Organizuj się wokół wartości.

Jakie są podstawowe opcje użycia SAFe?

SAFe proponuje nam cztery tzw. konfiguracje:

• Essential SAFe - opisuje najbardziej podstawowe oraz jednocześnie krytyczne elementy i ma na celu zapewnienie większości korzyści wynikających z frameworka. Dotyka poziomu zespołu i programu (który nazywa „agile release trains” lub ART).
• Large Solution SAFe umożliwia koordynację i synchronizację między wieloma programami, ale bez uwzględniania portfela. We wcześniejszych wersjach SAFe poziom ten był określany jako strumień wartości. 
• Portfel SAFe obejmuje kwestie związane z kierunkiem strategicznym, finansowaniem inwestycji i oszczędnym zarządzaniem.
• Full SAFe łączy w sobie pozostałe trzy poziomy.

Poznaj szczegóły i wizualizacje dla poszczególnych konfiguracji: https://www.scaledagileframework.com/#

Czym różni się SAFe od innych frameworków?

SAFe promuje dopasowanie, współpracę i dostarczanie produktu w dużej liczbie zwinnych zespołów, wykorzystując trzy podstawowe obszary wiedzy: zwinne tworzenie oprogramowania, tworzenie produktów metodą lean oraz myślenie systemowe. Podstawowym punktem odniesienia dla frameworka było opracowanie całościowego obrazu tego, jak praca przepływa od zarządzania produktem (lub innych interesariuszy), poprzez nadzór, zespoły programistów, aż do klientów. 

Scrum, XP czy inne zwinne metody wytwarzania oprogramowania analizują proces na poziomie pojedynczego zespołu. SAFe przenosi tę perspektywę na punkt widzenia kierownictwa firmy. Musi być więc zestawiany z takimi podejściami jak Scrum of Scrum, Scrum@Scale, Large-Scale Scrum czy Spotify. 

SAFe próbuje poradzić sobie z aspektami projektowymi, na które wcześniejsze frameworki nie dostarczały odpowiedzi osobom z wyższego managementu. Należą do nich:

• Radzenie sobie z odległym planowaniem - zespoły programistyczne zazwyczaj planują swój backlog prac z wyprzedzeniem od dwóch do trzech iteracji, ale w większych organizacjach zespół marketingu musi planować swoje zobowiązania rynkowe z dużo większym wyprzedzeniem. Często pracują na bardzo odległych terminach sięgających nawet 12 do 18 miesięcy, a następnie wspólnie z zespołami planują trzy miesiące pracy
• Utrzymywanie zwinności na abstrakcyjnych poziomach odpowiedzialności - chociaż zespoły programistyczne mają wiele frameworków i praktyk, które opisują, jak powinny pracować, to niewiele z nich dostarcza opis dla kierownictwa. SAFe dostarcza wiele takich samych zasad, jak np. zespoły wielofunkcyjne.
• Radzenie sobie z oddelegowaną odpowiedzialnością - w Scrumie oczekuje się, że właściciel produktu przejmie odpowiedzialność za cały cykl życia produktu, w tym zwrot z inwestycji, w decyzje dotyczące rozwoju, a także końcowe wyniki na rynku. W przypadku projektów na dużą skalę organizacja chce mieć wgląd w backlogi wielu zespołów i nie jest gotowa oddawać tak dużej władzy w jedne ręce.
• Synchronizacja dostaw - struktury zwinne są zaprojektowane tak, aby umożliwić zespołowi programistycznemu autonomię i swobodę prowadzenia prac. SAFe uznaje, że w skali wielu dziesiątek lub nawet setek zespołów programistycznych, pełna samoorganizacja zespołów staje się coraz bardziej chaotyczna. W związku z tym nakłada pewne ograniczenia i tam, gdzie zespoły pracują nad tym samym produktem, ich dostawy muszą być lepiej zsynchronizowane w celu osiągnięcia wspólnego releasowana.
• Zapewnienie czasu na innowacje i planowanie - cykl planowania SAFe zaleca uwzględnienie dodatkowej iteracji po wydaniu, aby zespoły mogły ulepszać swoje praktyki i były gotowe na kolejny przyrost. 

Scrum of Scrum zadziała w projektach do 20 zespołów; Scrum@Scale poradzi sobie lepiej w technologiach zorientowanych obiektowo i w organizacjach mniej biurokratycznych; Large-Scale Scrum będzie skuteczniejszy w organizacjach z eksperckim poziomem wdrożenia Srcuma z usunięciem pojęcia „zarządzanie projektami”; Spotify to rozwiązanie jeśli prowadzisz własny biznes.

SAFe ma wielu oponentów, którzy krytykują go za anty-agileowość, mieszanie sprzecznych praktyk, zbytnią złożoność itd. Jednak to rozwiązanie przemawia do wychowanych na ciężkich metodykach zarządczych managerów, którzy chcą połączyć swoje kaskadowe myślenie o wytwarzaniu produktu z jego zwinnym powstawaniem. 

Jakość w SAFe

Ponieważ na managerskim poziomie testowanie jest jedynie jedną z czynności, to już sam aspekt jakości jest odmieniany na wiele sposób. To, jak SAFe radzi sobie z dostarczaniem produktów wysokiej jakości, możemy odnaleźć w jego czterech podstawowych zasadach (ang. Core Values) i są to: Alignment, Built-in Quality, Transparency i Program Execution.

Alignment, czyli dopasowanie to w dużym uproszczeniu przeniesienie wizji kierownictwa do backlogu projektowego i jest to osiągniecie spójności wypracowywanych rozwiązań w różnych obszarach biznesowych organizacji i na różnych jej poziomach. Oczywiście musi być to zgodne ze strategią, wizją rozwoju produktów i roadmapą na jego dostarczenie. Poszczególne akcje i narzędzia używane na poziomie operacyjnym służą temu, żeby regularnie synchronizować się z biznesem oraz nadawanymi przez niego kierunkami rozwoju. Brak synchronizacji powoduje, że część rozwiązań pisanych jest do szuflady, okazuje się zdezaktualizowanymi już w momencie wdrażania albo mogłoby być zrealizowane lepiej, gdyby deweloperzy posiadali lepsze rozumienie biznesu i interesariuszy. 

Built-in Quality czyli wbudowanie jakości w produkt oznacza, że jakość musi być dostarczana poprzez dobre praktyki zespołów deweloperskich, a dodatkowo nie może być efektem procesów monitorowania i nadzoru. Ta wartość odnosi się bardzo mocno do praktyk deweloperskich wywodzących się wprost z Extreme Programming, ale zahacza też o podejście DevOps oraz Continuous Integration i Continuous Deployment.

Transparency oznacza otwartość w komunikacji na wszystkich poziomach organizacji i również pomiędzy nimi, dotyczy to również przejrzystości narzędzi i planów. Najwyraźniejszym tego przykładem są Kanbany funkcjonujące na wszystkich poziomach zarządczych i powszechnie dostępne dla interesariuszy. 

Program Execution podkreśla wagę dostarczania namacalnej wartości dla biznesu i użytkowników rozwiązań. Przekłada się, między innymi, na takie mechanizmy, jak Value Streams oraz Agile Release Train. Przypomina, jak ważne jest regularne dostarczanie działających rozwiązań, nawet jeśli są one cząstkowe i przynoszą częściowe korzyści poprzez umożliwienie zbierania informacji zwrotnych od interesariuszy.