Scrum określa zasady pracy dla jednego, kilkuosobowego zespołu deweloperskiego. Jednak coraz więcej projektów Agile jest prowadzonych przez kilkadziesiąt, kilkaset, a nawet kilka tysięcy ludzi. Ponieważ reguły komunikacji w Scrumie nie pozwalają nam skalować zespołów w nieskończoność (czyli upychać w nich więcej i więcej ludzi), pojawia się potrzeba skalowania poprzez wprowadzenie wielu zespołów. Dlatego firmy poszukują rozwiązań pozwalających na komunikacje, zarządzanie i efektywne wprowadzenie zmian w takim środowisku. Ostatnio coraz więcej szumu robi się dookoła Scaled Agile Framework albo SAFe. Zacząłem nawet dostawać pytania dotyczące wyłącznie tego frameworku. Czyli nawet nie „chcemy skalować swoją implementację Agile” a „chcemy SAFe”. Była więc najwyższa pora aby zasięgnąć języka i dowiedzieć się coś więcej na ten temat.
Skalowanie Zwinności
Zanim jednak popatrzymy na SAFe, ustalmy co to znaczy, że framework jest Agile. Dla mnie wymaga to posiadania trzech cech. Po pierwsze, musi opierać się na wartościach i zasadach opisanych w Manifeście Agile. Po drugie, musi być zależny od kontekstu organizacji. Po trzecie wreszcie, musi pozwalać na ciągłe doskonalenie.
1. Oparcie na wartościach i zasadach Agile
Pierwszy wymóg gwarantuje, że wprowadzone rozwiązanie będzie się skupiało na tym, co w tworzeniu oprogramowania najważniejsze, czyli częstym dodawaniem wartości dla klienta. Uzyskamy to poprzez koncentrację na czterech wartościach i dwunastu zasadach opisanych w manifeście. Tym samym położymy nacisk na uczestnikach projektu i zapewnieniu komunikacji między nimi oraz umożliwieniu proaktywnego dostosowywania produktu i procesów do zmieniającej się sytuacji. Inaczej mówiąc Agile, niezależnie od skali, oznacza sposób myślenia, a nie zestaw praktyk. Czyli „jestem Agile”, a nie „robię Agile”.
2. Kontekst firmy
Drugi wymóg zaręcza, że stosowane rozwiązanie będzie dopasowane do warunków konkretnej firmy. Inne oczekiwania ma przecież instytucja finansowa integrująca różne produkty (np. banki i firmy ubezpieczeniowe), inne koncern medyczny podlegający różnym normom bezpieczeństwa, inny telekom korzystający z zaawansowanych technologii, inny wreszcie firma tworząca głównie rozwiązania webowe. Każda z nich ma inne potrzeby i inne trudności. To co w jednym środowisku nie stanowi żadnego problemu, w innym może być poważnym wyzwaniem. Na przykład firmy webowe są w stanie wypuszczać zmiany w oprogramowaniu nawet kilka razy dziennie (np. Facebook), natomiast jest to bardzo trudne w przemyśle motoryzacyjnym i nie ma wartości biznesowej w przypadku tworzenia gier.
3. Ciągłe doskonalenie
Ostatni wymóg zapewnia wreszcie, że wprowadzona struktura nie jest ostateczna i organizacja będzie ciągle poszukiwała lepszych rozwiązań, dostosowując je do zmieniającego się otoczenia. Poszczególne zespoły powinny same dobierać procesy i narzędzia pozwalające najskuteczniej adresować stawiane przed nimi problemy. Powinny też ciągle podnosić sobie poprzeczkę, poprawiając procesy i dążąc do coraz trudniejszych celów. Również cała firma musi definiować i usprawniać strukturę organizacji, wspierając tym samym zespoły w realizacji ich celów.
Diabeł tkwi w szczegółach
Model SAFe bazuje na wybranych praktykach Agile, między innymi Scrumie i Kanbanie. Samo korzystanie z praktyk Zwinnych, nie przesądza jednak o byciu Agile. Można mieć codzienne spotkania, używać planning pokera, zdefiniować iteracje i dalej nie być w stanie reagować na potrzeby klientów, prowadzić projekt kaskadowo i zarządzać zespołami z pozycji władzy i kontroli. SAFe skupia się na zdefiniowaniu procesów i struktury organizacji nie biorąc pod uwagę ani powyższych trzech wymagań odnośnie bycia Agile, ani najważniejszego czynnika w tworzeniu oprogramowania, czyli ludzi. A przecież to oni, nie procesy i narzędzia, są odpowiedzialni za dostarczanie rozwiązań klientowi. Czyli ludzie i ich interakcje, nad procesy i narzędzia.
SAFe, dzięki dość dużej szczegółowości oraz dostępności certyfikowanych konsultantów daje zarządzającym przyjemne uczucie, że jest łatwy do wdrożenia. Po co skupiać się na największych wyzwaniach, które Scrum wyciąga na światło dzienne, kiedy można bezpiecznie wdrożyć SAFe. Sukces zostaje osiągnięty, nagrody przyznane. To, że wciąż nie rozwiązaliśmy naszych problemów i to, że ludzie postępują według procesów i praktyk SAFe a nie według wartości Agile, wydaje się nie być zauważane. Nic więc dziwnego, że SAFe jest krytykowany przez wielu ekspertów Agile, wliczając w to Kena Schwabera, współtwórcy Scruma oraz Davida Andersona, ojca Kanbana. Przy czym, w przypadku Kena, słowo krytyka, wydaje się być wręcz eufemizmem. Zarzuca on, że SAFe żeruje na sukcesie Agile, skupiając się jednak na procesach, nie ludziach, a więc łamie pierwszą wartość Agile. David dla odmiany zauważa, że zebranie w jednym miejscu grupy działających technik nie gwarantuje, że cały zbiór też będzie działać. To tak, jakby przebadać każdą część samolotu odrzutowego osobno i na końcu obwieścić, że samolot jest całkowicie bezpieczny. Inni autorzy, którzy spotkali się z SAFem zarzucają mu też między innymi rozmycie Definicji Ukończenia (Definition-of-Done) poprzez dodanie fazy „stabilizacji”, wprowadzenie Proxy Product Ownerów, czy ograniczenie zespołów deweloperskich do programistów i testerów, bez uwzględnienia pozostałych odpowiedzialności (architektury, UX, czy integracji).
Co ciekawe, autorem SAFe jest Dean Leffingwell, ojciec RUPa (Rational Unified Process). Biorąc pod uwagę, że jedną z głównych przyczyn stworzenia Manifestu Agile, była rebelia przeciwko narzucaniu RUPa i podejścia kaskadowego, to można powiedzieć, że historia zatacza koło. Być może wkrótce potrzebne będzie kolejne spotkanie w Snowbird, żeby wspólnie przeciwdziałać SAFe.
Czy jest alternatywa?
Wygląda na to, że jeżeli nie można być Agile, to zawsze można uzyskać certyfikat SAFe. Na dodatek, dzięki dobremu marketingowi SAFe wydaje się być jedynym rozwiązaniem dostępnym dla firm pragnących skorzystać z doświadczeń innych. Na szczęście tak nie jest. Coraz więcej firm rozumie pułapki skalowania Scruma i eksperymentuje z innymi podejściami. W ProCognicie, wspierając naszych klientów, poszukujemy innych rozwiązań, pozwalających „Skalować Agile” poprzez upraszczanie organizacji. Przeprowadzamy firmy przez zmiany bazując na modelu Large Scale Scrum (LeSS), opracowanym przez Claiga Larmana i Basa Vodde. LeSS został z sukcesem wdrożony w wielu firmach. W praktyce sprawdził się nawet przy tysiącach osób pracujących w wielu lokalizacjach na całym świecie. Nie jest on jednak tak sformalizowany jak SAFe. Opiera się na wartościach Agile i zakłada podejście prób i błędów, tak aby struktury, procesy i narzędzia zostały dostosowane do potrzeb organizacji, zespołu i produktu. Dlatego nasi Agile Coachowie pomagają firmom i zespołom zidentyfikować ich potrzeby i dobrać odpowiednie metody pracy. Nie narzucamy naszych rozwiązań, ale wspólnie z organizacją poszukujemy technik potrzebnych do efektywnego skalowania i skutecznej komunikacji. Pozwala nam to ograniczyć ilość procesów i zapewnić zwinny rozwój produktu. Przede wszystkim jednak skupiamy się na uczestnikach procesu zmiany: wytłumaczeniu potrzeby, zapewnieniu poczucia bezpieczeństwa i uzyskaniu ich aprobaty oraz wsparcia. Tym samym nowy model nie jest narzucany odgórnie, jest natomiast rozwijany przy współudziale wszystkich pracowników w oparciu o wartości Agile i Lean.
