W dzisiejszych czasach praktycznie nie ma już organizacji, które nie korzystałyby jakkolwiek z rozwiązań wypracowanych przez praktyków Agile. Dekomponowanie pracy w małe iteracje, luźna hierarchia organizacyjna zespołów, kładzenie nacisku na samoorganizację, a wszystko pod batutą Scrum Mastera / Product Ownera / Proxy Product Ownera / Agile Project Managera / czy jakkolwiek byśmy nie chcieli nazwać roli osoby zlecająco-nadzorującej pracę zespołu. Rozwiązania zwinne są bardzo dobre dla małych i średnich zespołów zaangażowanych w dane przedsięwzięcie, ponieważ dają interesariuszom możliwość szybkiego wglądu w pracę oraz gwarantują bardzo dużą reaktywność na zmiany w otoczeniu projektu.
Co jednak w przypadku projektów o bardzo dużych rozmiarach, nakładach pieniężnych, albo takich przy których potrzeba specjalistów z różnych działów danej organizacji? Z pomocą przychodzą frameworki, które można wdrożyć w organizację i według nich pracować.
Najpopularniejszymi szkieletami dla takich przedsięwzięć są SAFe (Scaled Agile Framework) oraz Nexus. Większość firm decyduje się na pierwsze rozwiązanie ze względu na mnogość konsultantów oraz „trenerów” SAFe, którzy prowadząc za rękę osoby decyzyjne w organizacji ukazują idealny świat oraz definiują role projektowe dla pracowników. Nie chciałbym przedstawiać szczegółów dotyczących tego frameworka zainteresowanych odsyłam do odpowiedniej strony ( https://www.scaledagileframework.com ). To, co nas interesować powinno to fakt, że jest to framework, który tworzy podorganizację w ramach organizacji właściwej. W niniejszym artykule postanowiłem pokazać największe „grzechy” tego rozwiązania i zaproponować lekkie zmiany, które są potrzebne organizacjom, chcącym zaimplementować SAFe w ramach swojej organizacji.
Obraz 1: Od ilości karteczek na Kanbanie można stracić głowę!
CZY TO JESZCZE JEST ZWINNE ?
I tak i nie. Na początku trzeba poświęcić bardzo dużo czasu analityków, osób merytorycznych i biznesu, aby przygotować odgórny backlog Programu, który w idealnym świecie nie powinien ulegać zmianie przez czas trwania projektu. Następnie należy przeprowadzić Program Increment Planning (PIP) – duże jedno/ kilkudniowe spotkanie ze wszystkimi zespołami i członkami zespołów w ramach projektu. I to jest dobre, czyste, zgodne ze Scrumem. Pojawia się natomiast pewne „ale”… Planningi są przeprowadzone co 2/3 miesiące, w związku z czym reaktywność jest praktycznie zerowa. Najważniejsze dla kilku trenerów SAFe, z którymi rozmawiałem jest pokazanie głównym interesariuszom, że produkty programu są dostarczane i namacalne. Problem też pojawia się na PIP w ramach spotkania – zespoły są zachęcane do minimalnej interakcji między sobą, badania zależności, wskazywania ryzyk dla zadań. Natomiast nie promuje się podejścia do rozmów zespołów per zadanie/epic aby rozpisać treść, podzadania, główne efekty oraz Definition of Done. Po jednej iteracji znajdujemy się w sytuacji, w której problemy, których nie rozwiązaliśmy w sprincie nawarstwiają się. W związku z czym dostajemy hybrydę waterfalla podszytego Agile’m.
Obraz 2: I wszystko proste, prawda? No tak nie do końca…
CZY TO MA SENS ?
Chciałbym nadmienić, że pomimo mojego sceptycyzmu nie jestem totalnym wrogiem SAFe. Uważam, że po prostu nie każda organizacja powinna wprowadzać SAFe. Brałem udział jako Analityk przy wdrożeniu SAFe w ramach jednego z moich poprzednich klientów w ramach bardzo dużego przedsięwzięcia, na które składało się kilka drobnych projektów. Zaangażowanych było około 40 członków „produktywnych” (programistów front-end, programistów back-end, ludzie od Szyny, zespół SAP, zespół CRM, zespół obsługujący jeden z produktów eCommerce) oraz dość zbliżona liczba osób z tzw. overheadu: dział analizy, architekci, osoby merytoryczne z różnych pionów organizacyjnych, team leaderów, product managerowie per projekt, scrum masterzy per projekt, interesariusze w postaci dyrektorów oraz kilka innych osób. Dla tych ostatnich SAFe był tak naprawdę narzędziem zbierającym kilka projektów w jeden program oraz narzucającym dodatkowe odpowiedzialności ludziom pracującym na różnych stanowiskach w organizacji. Nie miało to sensu, ponieważ narzucało to członkom zespołu oprócz swojej pracy codziennej wykonywanie prac przygotowawczych do kolejnych sprintów w ramach programu.
Kolejną wadą SAFe jest brak uregulowania świata programu-projektu w ramach organizacji. Nie wspomina, w żadnym ze swoich założeń relacji między stanowiskiem w organizacji a stanowiskiem w całym programie. Przy takich niejasnych „relacjach stanowiskowych” mogą wystąpić konflikty interesów.
Dodatkowo w ramach prac Release Train Managera (Łączonej roli Project Managera oraz Scrum Mastera, który ma odpowiadać za prace innych project managerów) nie istnieje zarządzanie ryzykiem. Rejestr nie powstaje, bo nie obejmuje go metodyka poza PIP, na którym zespoły mają wróżyć z fusów i wymyślać ryzyka bez faktycznej szansy jego wystąpienia. Naturalnym jest fakt, że każda niedowieziona funkcjonalność, która ma wpływ na pracę innego zespołu istnieje dość duże ryzyko na generowanie sporych opóźnień w ramach całego programu. Framework zakłada, że zespół potrafi wyszacować swoją pracę na dwa/trzy miesiące w ramach dwutygodniowych sprintów. Niestety stanowisko wróżbity nie jest definiowane w ramach SAFe…
ROZWIĄZANIE?
Według mnie w programie o wspomnianej przeze mnie wcześniej skali lepszym i przede wszystkim tańszym rozwiązaniem byłoby utworzenie stanowiska Program Managera, który stojąc ponad Project Managerami i Product Ownerami byłby w stanie zarządzać potrzebami biznesowymi oraz ryzykiem. Wskazywałby kierunek rozwoju poszczególnych projektów w ramach całości.
Mam nadzieję, że powyższy artykuł zachęci Was, szanownych czytelników do zaczerpnięcia wiedzy zarówno o SAFe jak i Nexusie oraz do wyrobienia sobie własnego zdania.
Obraz 3: Bo nie każdy Superbohater nosi pelerynę, ale bez niej średnio wygląda 🙂
