Wielkoskalowa implementacja Agile. Case study Ericsson

Nie będzie to kolejny artykuł traktujący o pryncypiach, praktykach, artefaktach czy rolach Scruma czy Kanbana. Nie będzie to kolejna rozprawa o tym, jak i dlaczego używamy story pointów czy idealnych godzin. Nie omówię tutaj także sposobów budowania zespołu Scrumowego, ról w teamie czy budowy backlogu. Skupię się za to na sposobie, jaki przyjąłem przy wprowadzeniu Agile w Ericsson, a nie jest to mała i jednorodna firma.

Źródło: Ericsson

Jak to się zaczęło

Na początku 2019 roku zostałem poproszony o sprawdzenie kondycji Agile dla wszystkich zespołów programistycznych przypisanych do danej jednostki organizacyjnej. Miałem także za zadanie zaproponować szkielet Agile pozwalający na ciągłe doskonalenie się organizacji. Cała inicjatywa miała służyć i wspierać ponad dwadzieścia sześć zespołów pracujących na rzecz łącznie pięciu rozbudowanych programów, w czterech różnych lokalizacjach na całym świecie oraz rozproszonych biurach.

Bazując na tych danych, rozpocząłem od zbadania środowiska, w którym przyjdzie mi pracować oraz budowania sieci kontaktów. Byłem w tyle komfortowej sytuacji, że kierownicy wyższego szczebla, rozumieli potrzebę budowania środowiska Agile w organizacji i nie ukrywam, że było to jedno z kluczowych elementów pozwalających na powodzenie całej inicjatywy.

Rozmowa, diagnoza problemu, wywiad (odpowiadający temu lekarskiemu), rozeznanie się w obecnej sytuacji; zbieranie opinii i poglądów z różnych źródeł oraz perspektyw jest dobrą praktyką. Dzięki temu projekt, jak i każdy z nas znajdujący się w nowych sytuacjach, nie działa po omacku, bazując na własnych często błędnych założeniach.

Planowanie inicjatywy – narodziny koncepcji

Planowanie nie rozpoczęło się typowo, ponieważ nie był to projekt typowy. Wszyscy w organizacji pochodzili z różnych lokalizacji, mając inne doświadczenie i podejście kulturowe. Zrozumienie samego Agile było również niejednorodne. Dlatego ważnym stało się ujednolicenie, wspólne zrozumienie i wykreowanie środowiska samodoskonalącego się wśród pracowników.

Wyszedłem również z założenia, że nie warto skupiać się nad stworzeniem idealnego procesu Agile, ale raczej na rezultatach, które mogą wyniknąć z tworzenia wspólnego szkieletu, definicji, rozumienia dobrych praktyk czy technik itp.

Planowanie poprzedziłem szerokim „dochodzeniem” i badaniem potrzeb poszczególnych interesariuszy. Z racji tego, że inicjatywa wyszła bezpośrednio od kierowników liniowych, zdecydowałem o rozpoczęciu serii spotkań z każdym z kierowników z osobna. Z każdego zespołu developerskiego należało też wyznaczyć reprezentanta. Oczywiste było to, że należy stworzyć kilka zespołów zdalnych (5-7 członków każdy), w skład których wchodzili wspomniani reprezentanci.

Kolejnym krokiem były spotkania indywidualne z każdym z reprezentantów oraz przedstawienie ogólnej wizji, koncepcji, a także uszczegółowienie metody pracy i dostarczania rezultatów. Powołałem również tzw. grupę referencyjną stworzoną z osób decyzyjnych, na której prezentowany był status i aktualny postęp prac. Zebrane materiały pozwoliły mi na stworzenie listy elementów (backlog), których wykonanie pozwalało na osiągnięcie wspomnianego celu.

Agile (w szczególności oparty na metodyce Scrum) często jest wyidealizowany i wprowadzany w sposób bezkrytyczny w organizacjach. Przed podjęciem decyzji o jego wprowadzeniu, trzeba sobie zadać pytanie, czy to jest to odpowiedni moment. Każda zmiana pociąga za sobą szereg odpowiedzialności po stronie osób chcących ją wprowadzić. W tym przypadku, ale również wierzę, że w każdym innym, nikt nie jest w stanie nic zmienić bez wsparcia całej organizacji.

Jeżeli zamierzasz wprowadzić zmianę (dużą lub małą) zadbaj o to, aby ludzie rozumieli, czym ona jest, co za sobą niesie i co z tego będą mieli. Pozwól im również na to, żeby sami ją kreowali i wprowadzali. Zyskasz dzięki temu bezcenny zespół reprezentantów, którzy będą pracować wraz z Tobą nad przekonaniem do zmiany swoich kolegów z biurka obok.

Cel zmiany

Można by spytać, co z wprowadzenia Agile będzie miała firma, a co pracownik? Jaki jest benefit, a jaki cel? Nie jest to łatwe do określenia. W tym przypadku wspomniane dochodzenie, badanie potrzeb i problemów oraz współpraca pozwoliły na zdefiniowanie poniższego celu:

• skupienie na interdyscyplinarnych i samoorganizujących się zespołach,
• wspólne rozumienie Agile,
• 3-4 zdefiniowane metodologie pracy w Agile (Scrum, Kanban, Scrumban, MOP),
• ułatwienie pracy poprzez jasno określone wytyczne i wskazówki,
• wspólna terminologia i definicje,
• zdefiniowane techniki, narzędzia, standardy, dobre praktyki,
• polepszenie współpracy i motywacji osób.

Dzięki realizacji tych celów firma, interesariusze, jak i członkowie zespołów dostarczą benefit w postaci:

• wysokiej jakość oprogramowania,
• satysfakcji interesariuszy projektów i programów,
• większej kontroli projektu/produktu,
• analizy ryzyka, kosztu, czasu dostawy oraz planowania,
• widoczności procesu wytwarzania oprogramowania,
• dostosowywanie się do zmian,
• efektywność.

Jak widzisz, cel jest zdefiniowany dość wysokopoziomowo i na pierwszy rzut oka ciężko wyciągnąć esencję potrzebną do przekonania załogi, dlaczego mają wprowadzać tę konkretną zmianę. Cel i benefit powinien być określony, jak również jego uzasadnienie, profit dla pracownika przedstawione i wytłumaczone (dlaczego wysoka jakość oprogramowania jest ważna dla Ciebie drogi programisto, co oznacza efektywność itp.).

Przemyślana odpowiedź na pytanie „dlaczego” jest ważna. Zwracam Ci szczególną uwagę na to, że „odpowiedź” będzie się zmieniać w czasie (zmiany tego typu trwają rok lub dwa). Dlatego ważne jest, aby zadbać o zgodność z rzeczywistością, obecną sytuacją i realnymi potrzebami pracowników.

Praca w organizacji i z organizacją

Po przygotowaniach nastąpił moment rozpoczęcia prac nad zbudowaniem rozwiązania Agile dedykowanego dla naszych potrzeb przy realiach, w których pracujemy. Każdy z czterech zespołów zdalnych rozpoczynał pracę nad jednym z elementów backlogu. Miał na to odpowiednią ilość czasu. W ramach prac zespół miał stworzyć jak najdokładniejszy opis zagadnienia wraz z dedykowaną skompensowaną informacją w postaci jednego slajdu. Opis był dedykowany liderom zmiany. Slajdy z zagadnień miały stworzyć zbiorczą prezentację pomagającą liderom na wdrożenie Agile.

Na koniec dnia miało powstać szesnaście opisów i szesnaście slajdów. Każdy z opisów zawierał informację:

• co jest opisywane,
• dlaczego jest istotne z punktu widzenia Agile i firmy,
• jak to stosować,
• kiedy to stosować,
• podział na role i odpowiedzialności,
• dobre praktyki,
• terminologia,
• model dojrzałości – o tym opowiem trochę później.

Przy tworzeniu szkieletu zespoły skupiają się na:

• dopasowaniu do kontekstu i środowiska organizacji,
• szerzenia świadomości i zaangażowania, wymiany wiedzy, obecnie przyjętych praktyk,
• dostarczeniu jasnych i rzetelnych wskazówek,
• zbudowaniu wspierającej się kultury.

Przygotowane dokumenty trafiają do przeglądu. W pierwszej kolejności do pozostałych zdalnych zespołów, a w końcu do osób decyzyjnych z grupy referencyjnej. Proces przeglądu dokumentów pomaga także w szerzeniu wiedzy i świadomości wśród liderów, jak i wnosi poprawki do samych dokumentów. Tak przygotowany finalny produkt jest gotowy do fazy integracji, czyli wdrożenia do zespołów programistycznych i utrzymaniowych.

Zauważ, że wszyscy współpracują przy tworzeniu Agile. To jest ich praca, wiedza, doświadczenie, ich pomysły i poszukiwania. Twoim zadaniem jest stworzenie środowiska, struktury współpracy oraz pozostałych elementów technicznych (spotkania, dokumenty, stroną do kolaboracji itp.). Pozostałą część pozostaw załodze, a Ty sam przeobraź się w trenera lub nawet mentora.

Źródło: Ericsson

Integracja – wdrożenie Agile Framework

Ważnym etapem w całym przedsięwzięciu było zaplanowanie fazy wdrożenia przygotowanych koncepcji. Należało to wykonać stopniowo i z rozwagą, by nie zaburzyć bieżących prac i nie zdemotywować załogi. Odpowiedzialność za wdrożenie, utrzymanie i monitorowanie spoczywały na Kierownikach Liniowych (zwanych dalej Agile Coach).

Proponowany proces wdrożenia składał się z:

• zaznajomienia się z opisem jednego z elementów backlogu,
• użycia obecnej lub przygotowanie dedykowane prezentacji wspomagającej,
• oceny dojrzałości zespołu,
• wytłumaczenia powodów wdrożenia szkieletu Agile,
• przygotowania wspólnego planu osiągnięcia odpowiedniego poziomu dojrzałości razem z zespołem,
• dopasowania planowanych zmian z obecną pracą w projekcie do tempa pracy,
• potwierdzenia zrozumienia zagadnienia,
• zebrania informacji zwrotnej.

Do dyspozycji Reprezentantów Agile i Kierowników (Agile Coach) są nie tylko opisy i slajdy, ale również wspomniany Model dojrzałości. Model zakładał ocenę każdego zespołu pod kątem dojrzałości Agile. Przyjęta skala to 1– nieoceniony, 2 – podstawowy, 3 – średniozaawansowany, 4 – zaawansowany, 5 – biegły (pełna samoorganizacja i odpowiedzialność). Każdy opis zawiera sekcję poświęconą modelowi dojrzałości. W sekcji tej przedstawiono, co jest rozumiane poprzez konkretny poziom modelu.

Proces oceny wygląda następująco:

• ocena reprezentanta z zespołu developerskiego, który brał udział w przygotowaniu szkieletu Agile,
• samoocena zespołu developerskiego (weryfikacja),
• ocena Agile Coach (weryfikacja).

Zespoły oceniają się w kilkunastu kategoriach, a trzystopniowa ocena pozwala na rzeczowe podejście do tematu dojrzałości Agile.

Grupa referencyjna określiła także cele dla zespołów programistycznych pod kątem rekomendowanego poziomu dojrzałości dla wszystkich opisanych elementów. Zespoły wiedzą zatem jaki mają minimalny cel do osiągnięcia, a model dojrzałości pomógł im w zdobyciu odpowiedniej dojrzałości Agile.

Wiadome jest, że z Agile wiąże się ciągłym doskonaleniem poprzez informację zwrotną. Sam stworzony szkielet Agile podlega tym samym zasadom, co jest ważne z punktu widzenia fazy utrzymaniowej. Niezmiernie istotne jest sprawdzanie postępów. Odradzałbym wprowadzanie komisji ewaluacyjnych, oficjalnych audytów czy skrupulatnych kontroli. To nie jest ten etap. Kładzenie skupienia na kilkuetapową samocenę pozwala na zachowanie subtelnej kontroli nad postępami oraz retrospektywę zespołu.

Utrzymanie

Może się zdarzyć, że zespół chce podążać własnym wypracowanym sposobem pracy, który nie jest opisany w szkielecie Agile. Wymaga to przygotowania na bazie doświadczeń opisu i slajdu, przejście całego procesu przeglądu i prezentacja tego sposobu do całej organizacji. Najczęściej spotykamy to przy zespołach o najwyższym poziomie dojrzałości.

Utrzymanie polega również na ciągłym cyklu informacji zwrotnej z zespołów programistycznych do Agile Coach i Reprezentantów, która pomaga w ciągłym doskonaleniu szkieletu Agile. Zakłada się, że zespoły osiągające poziom 5 w modelu dojrzałości, dzielą się swoimi doświadczeniami samoorganizacji z pozostałymi zespołami i wszyscy ciągle pracują nad wymianą wiedzy oraz spostrzeżeń.

Źródło: Ericsson

Podsumowanie

Tylko poprzez kooperację, adaptowanie się do zmian, małe kroki w zrównoważonym tempie przy wzajemnym szacunku, odpowiednią przestrzeń (psychiczną) dedykowaną dla uczestników, otwartość i aktywne słuchanie jesteśmy w stanie wypracowywać dopasowany do naszych realiów i organizacji szkielet Agile oraz poprawnie wprowadzić zmianę.

Natomiast jako lider Twojej zmiany (niezależnie od tego, czego zmiana dotyczy) zadbaj o kilka istotnych kwestii.

1. Rozpoznaj sytuację, w jakiej przyjdzie Ci pracować.
2. Zadbaj o sieć kontaktów.
3. Znajdź reprezentantów zmiany. To oni są kluczowi, nie Ty.
4. Określ cel i benefit.
5. Wytłumacz, dlaczego jest to ważne i jaki pozytyw płynie z tego dla pracownika.
6. Zawsze dopasuj działania do aktualnego kontekstu.
7. Bądź trenerem lub mentorem, a nie dyktatorem czy kierownikiem.
8. Pozwól ludziom pracować i realizować pomysły oraz zabezpiecz niezbędne elementy ułatwiające współpracę.
9. Subtelna kontrola, samoocena i retrospektywa.
10. Dbaj o zachowanie wypracowanych rezultatów.

---

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z