W dzisiejszych czasach, kiedy przedsiębiorstwa przenoszą swoje systemy informatyczne z tradycyjnych serwerowni do środowisk chmurowych, często priorytetem staje się osiągnięcie większej „elastyczności”. W idealnym scenariuszu, ta zmiana powinna objąć wszystkie aspekty działalności na poziomie międzyorganizacyjnym i wdrożyć się sprawnie i jednocześnie w każdym obszarze.
Przekształcenie procesów teoretycznie wydaje się proste. Można wprowadzić ceremonie scrumowe i przypisać ludzi do nowych ról, takich jak scrum masterzy, właściciele produktów, menedżerowie dostaw i zespoły scrumowe.
Można również wdrożyć narzędzia takie jak Jira, Azure ADO i Miro Board, czyniąc je standardem pracy. Jednak co z procesami, które łączą te narzędzia w całość? Co z adaptacją ludzkich umysłów, zachowań i sposobu pracy? Szybko staje się jasne, że nie jest to proces, który przebiegnie gładko i szybko. Zastanówmy się, dlaczego tak się dzieje.
Czym jest inicjatywa transformacji dostaw i jakie są jej przyczyny?
Wiele firm nadal bazuje na klasycznym modelu kaskadowym. Oznacza to, że proces przebiega następująco:
- Najpierw ustala się, jaki ma być finalny rezultat/produkt oraz szacuje się przybliżony koszt jego wytworzenia.
- Następnie rozpoczyna się proces zbierania szczegółowych wymagań. W jego trakcie każdy aspekt produktu jest dokładnie analizowany, kwestionowany, uzgadniany i ostatecznie zatwierdzany.
- Na podstawie zebranych wymagań ponownie szacuje się koszty i potwierdza oczekiwania budżetowe.
- Kolejnym krokiem jest zaprojektowanie rozwiązania. Wymaga to szeregu spotkań z interesariuszami, tworzenia dokumentacji i uzyskiwania ich akceptacji. Finalnie zatwierdza się ostateczny projekt funkcjonalno-techniczny.
- W oparciu o projekt następuje implementacja rozwiązania. To w tej fazie powstaje finalny produkt.
- Następnie przechodzi się do fazy testowania, która obejmuje różnorodne testy, m.in.: testy jednostkowe, systemowe, funkcjonalne, integracyjne, wydajnościowe, regresyjne i akceptacyjne. Wyniki testów są dokumentowane i przekazywane do akceptacji interesariuszom.
- Po testach następuje wdrożenie rozwiązania w środowisku produkcyjnym, gdzie użytkownicy końcowi mogą zacząć z niego korzystać.
- Ostatnim etapem jest faza wsparcia, podczas której zespół programistów usuwa potencjalne błędy.
Cały ten proces może trwać od kilku miesięcy do nawet kilku lat. Jak widać, użytkownicy zobaczą efekty dopiero na samym końcu tego cyklu. Po długim okresie oczekiwania następuje moment prawdy.
Jeśli w międzyczasie nastąpią zmiany i finalny produkt będzie wymagał modyfikacji, konieczne jest ponowne otwarcie projektu, jego przerobienie i ponowne zatwierdzenie. Taka sytuacja wydłuża cały proces.
Oczywiście, taki model nie ma nic wspólnego z elastycznością. Każda zmiana wymaga ponownego uruchomienia całego procesu.
Przejście na metodykę Agile
Jak zatem można wyjść z tego schematu i wprowadzić metodykę Agile? Ludzie przez lata, a nawet wieki, pracowali w modelu kaskadowym. Są przyzwyczajeni do swoich ról i obowiązków i niechętnie zmieniają status quo. Głównym powodem takiego oporu jest to, że wprowadzenie zmian może wiązać się z utratą dotychczasowej pozycji i władzy.
To właśnie ten aspekt sprawia, że zmiana ta napotyka na największy opór.
#1. Restrukturyzacja zespołów
Pierwszym krokiem, i stosunkowo najłatwiejszym, jest przeorganizowanie ludzi w zespoły scrumowe. Można ich podzielić na podstawie obszarów funkcjonalnych lub w inny logiczny sposób.
Podział zazwyczaj przebiega bez większych problemów. Problem pojawia się, gdy okazuje się, że ludzie wciąż są przywiązani do starych struktur. Mimo formalnego dołączenia do nowych zespołów scrumowych, w praktyce nadal pracują w starym układzie, realizując swoje dotychczasowe zadania. Wynika to z tego, że kierownictwo nie skupia się na zakończeniu starych projektów, ale na rozpoczęciu nowych.
W efekcie powstaje zespół scrumowy, który tak naprawdę nie jest w pełni dedykowany. To grupa ludzi, która ma po prostu więcej pracy. Członkowie zespołu scrumowego nie mają tyle czasu na pracę, ile zakłada kierownictwo.
Jednocześnie od ludzi oczekuje się realizacji starych zadań i nowych zadań w ramach zespołów scrumowych. To konfiguracja, która od początku jest skazana na porażkę.
#2. Planowanie ceremonii Scrum
Ustalenie harmonogramu regularnych spotkań zespołów (ceremonii sprintu) jest łatwe do zdefiniowania i wdrożenia. Przynajmniej w teorii, jeśli zespoły scrumowe nie składają się z osób z różnych stref czasowych (co jest częstym zjawiskiem).
Problem pojawia się, gdy ludzie nie chcą regularnie uczestniczyć w ceremoniach. W zależności od tego, kto i jak często opuszcza spotkania, może to prowadzić do różnych problemów. Na przykład:
- Brak obecności właścicieli produktów na ceremoniach planowania i udoskonalania skutkuje brakiem nowych zadań dla zespołu. Lub opisy zadań są niekompletne, co uniemożliwia rozpoczęcie pracy.
- Brak scrum masterów na spotkaniach prowadzi do braku koordynacji i w konsekwencji zespół może stracić orientację.
- Częsta nieobecność członków zespołu programistów utrudnia synchronizację i komunikację. Ponadto, aby nadrobić zaległości, potrzebne są dodatkowe spotkania, co pochłania cenny czas zespołu.
Ostatecznie nie zawsze jest to wina ludzi, że nie uczestniczą w ceremoniach. Często konfiguracja pracy nie pozwala im na regularne uczestnictwo (patrz: równoległe, wcześniejsze zadania).
#3. Stabilność zespołu
Możemy mieć zespół scrumowy z ustaloną strukturą i harmonogramem ceremonii, ale jeśli ten zespół nie będzie stabilny przez dłuższy okres czasu – idealnie co najmniej pół roku, a moim zdaniem minimum rok – to taki zespół nie ma szansy na rozwój i doskonalenie się.
W takiej sytuacji prawdopodobnie nigdy nie doczekamy się w pełni samodzielnego zespołu scrumowego, który sprawnie realizuje sprinty. Dodatkowo, konieczne będzie ciągłe szkolenie i edukowanie nowych członków zespołu w zakresie zasad i procesów scrumowych. To bardzo wyczerpujący problem.
Ten aspekt jest często niedoceniany, szczególnie przez kadrę zarządzającą. Traktowanie zespołów ludzkich jako „zasobów” i planowanie ich „wykorzystania” z kwartału na kwartał to prosta droga do niepowodzenia.
#4. Nowe role dla tych samych osób
Kolejnym wyzwaniem jest przydzielanie dotychczasowych pracowników do nowych ról. Osoby, które wcześniej zarządzały zespołami, mogą teraz zostać na przykład właścicielami produktu. Chociaż jest to ważna rola w zespole scrumowym, może być postrzegana jako mniej prestiżowa od dotychczasowej.
Właściciele produktów muszą teraz współpracować ze scrum masterami i menedżerami programów. Nadal odpowiadają za treść, ale mają mniejszy wpływ na proces dostarczania. Taka zmiana wymaga rezygnacji z części dotychczasowych obowiązków, co nie jest łatwe do zaakceptowania.
#5. Sposoby pracy
Często słyszę, że musimy nauczyć się nowych sposobów pracy, aby zachować konkurencyjność na dynamicznie zmieniającym się rynku, gdzie elastyczność jest kluczowa. Ale co tak naprawdę oznaczają te „nowe sposoby pracy”?
Moim zdaniem, kierownictwo ma na myśli osiąganie (znacznie) więcej w krótszym czasie. Po utworzeniu zespołów scrumowych oczekuje się, że każdy członek zespołu zacznie od razu dostarczać przyrostowe efekty. Jeśli tak się nie dzieje, kierownictwo zaczyna zastanawiać się, dlaczego metodyka Agile nie działa prawidłowo.
Kierownictwo zakłada, że każda godzina pracy jest produktywna i że zespoły scrumowe nie będą miały przestojów. Nie ma jednak czasu na to, aby wszystkie procesy scrumowe mogły zostać wdrożone prawidłowo. Tak można podsumować „nowe sposoby pracy” z perspektywy kierownictwa.
Oczywiście, to założenie nie ma wiele wspólnego z rzeczywistością. Iluzją jest oczekiwanie, że ludzie zaczną pracować więcej tylko dlatego, że zmienią się niektóre codzienne procesy. Być może niektórzy tak zrobią, ale będzie to mniejszość. Nawet ta grupa zostanie ograniczona przez obciążenie ich większą ilością zadań.
Różnica między założeniami a rzeczywistością
Założenia dotyczące wdrożenia Agile zazwyczaj są trafne i sensowne. Opierają się na następujących zasadach:
- Stabilne zespoły scrumowe pracujące na niezależnych backlogach z jasno określonymi wskaźnikami KPI i OKR.
- Właściciele produktów tworzący solidne plany działania i planujący treści według ustalonych priorytetów.
- Określona zawartość backlogu z wyszczególnionymi funkcjonalnościami przed rozpoczęciem pracy.
- Niezawodne procesy testowe realizowane równolegle z pracami programistycznymi w sprincie.
- Regularne wdrożenia na produkcję – przynajmniej raz w miesiącu, a idealnie po każdym sprincie.
- Śledzenie ryzyka i problemów oraz komunikacja między różnymi zespołami scrumowymi w przypadku zależności.
Jednak w praktyce, żaden z powyższych punktów nie jest łatwy do osiągnięcia.
- Zespoły scrumowe są tworzone, ale ciągle się zmieniają. Poświęca się czas na szkolenie zespołu z zasad Scrum, a gdy zaczynają je rozumieć, następuje reorganizacja. Plany są modyfikowane, przesuwane lub anulowane.
- Właściciele produktów nie znają szczegółów planu działania i (z przyzwyczajenia) przydzielają zadania dotyczące budowy backlogu bezpośrednio zespołowi. W rezultacie zespół nie ma czasu na tworzenie treści, ponieważ najpierw musi zrozumieć, co ma zrobić.
- Testy są przeprowadzane wyłącznie ręcznie i wymagają wielu etapów, zatwierdzeń i skomplikowanych procedur. Oznacza to, że testowanie nie jest możliwe do zakończenia w tym samym sprincie, co prace programistyczne.
- W konsekwencji, wdrożenie na produkcję jest opóźnione o kilka sprintów.
- Komunikacja pomiędzy zespołami jest chaotyczna i nieefektywna. Każdy zespół ma zbyt wiele zadań do wykonania w każdym sprincie. Właściciele produktów mają tendencję do przypisywania zespołowi nadmiernej ilości pracy. Zespół nie jest w stanie wszystkiego ukończyć, dlatego stale pracuje pod presją czasu.
Korygowanie błędów
Bazując na doświadczeniu z kilku projektów transformacji Agile, chciałbym podsumować najczęściej popełniane błędy i przedstawić subiektywne sugestie, jak ich uniknąć.
#1. Właściwe obowiązki i role
Próba zmiany definicji i zakresu obowiązków w Scrum/Agile prowadzi do niepowodzenia całej inicjatywy.
- Właściciele produktów są odpowiedzialni za treść i utrzymanie backlogu. Jeśli historie w backlogu są źle zdefiniowane, to ich zadaniem jest podjęcie działań naprawczych. Nie powinni mieć wpływu na przydzielanie zadań członkom zespołu scrumowego ani na decyzje budżetowe projektu.
- Scrum masterzy nie są odpowiedzialni za zawartość backlogu. Ich zadaniem jest koordynowanie ceremonii i edukowanie zespołu w zakresie efektywnej pracy. Nie powinni pełnić roli sekretarzy właścicieli produktów. Wręcz przeciwnie, powinni chronić zespół programistów przed wpływem właściciela produktu i innych interesariuszy.
- Każdy zespół scrumowy powinien mieć lidera dostaw. Ta osoba łączy właściciela produktu, scrum mastera i zespół programistów, definiuje procesy dostawy i rozwiązuje wszelkie problemy, ryzyka i konflikty. Lider dostaw decyduje o sprawach kadrowych i budżetowych projektu. Powinien dążyć do stworzenia środowiska pracy, w którym każdy może dać z siebie wszystko.
- Zespół programistów odpowiada za realizację zadań z backlogu. Mogą pomóc właścicielowi produktu w tworzeniu treści dla zadań, które są bardziej techniczne, ale nie są odpowiedzialni za ogólną treść planu działania.
#2. Stabilny zespół
Inwestycja w szkolenie zespołu jest istotna i musi przebiegać sprawnie. Ignorowanie tego aspektu co kilka miesięcy to strata czasu dla wszystkich.
Pierwsze pięć sprintów można wykorzystać na naukę i praktykę podstawowych zasad Scrum. Gdy staną się one jasne dla zespołu, można rozpocząć proces ciągłego doskonalenia. Jeśli skład zespołu będzie się regularnie zmieniał, będziemy w ciągłej pętli transferu wiedzy i szkolenia nowych członków.
Taki zespół prawdopodobnie nigdy nie osiągnie pełnego potencjału, a kierownictwo będzie się zastanawiać, dlaczego przed transformacją Agile praca była bardziej efektywna.
Zbuduj stabilny zespół, zainwestuj w jego wiedzę i, gdy zespół zacznie działać sprawnie, pozwól mu działać. To jest początek drogi do doskonałości.
#3. Matryca RACI
Dobrym rozwiązaniem jest stworzenie i uzgodnienie matrycy RACI (Responsible, Accountable, Consulted, Informed) pomiędzy wszystkimi zespołami przed rozpoczęciem pracy. Pozwala to uniknąć wielu nieporozumień.
Jest to szczególnie istotne na wczesnych etapach transformacji. W przeciwnym razie ludzie będą zadawać pytania o to, kto jest za co odpowiedzialny, szczególnie w sytuacjach, które nie zostały wcześniej omówione.
Poniżej znajduje się przykład matrycy RACI dla przykładowych obowiązków. W Twoim projekcie mogą występować inne zadania, ważne jest aby wszystkie istotne zadania były uwzględnione w matrycy.
Zadanie Kierownik dostawy Właściciel produktu Scrum Master Zespół programistów
Sesje planowania sprintu C/I I A/I R C/I D
Przyrost wersji dostawy N/A I A/I I R
Przegląd wydruku C/I I R I C S R
Retrospektywa druku I I A/I R C/I R
Sprawdź zaległości I A/I R A C/I
Podsumowanie
Można by jeszcze wiele napisać, ponieważ istnieje wiele aspektów transformacji Agile, które mogą pójść nie tak. Celem tego artykułu było zwrócenie uwagi na najczęściej powtarzające się problemy.
Sama inicjatywa wdrożenia Agile jest dobrym pomysłem. Jednak bez przestrzegania kilku podstawowych zasad, może szybko zamienić się w koszmar. W tym artykule podkreśliłem kilka z nich. Kieruj się zdrowym rozsądkiem i wszystko będzie dobrze. 🙂
Na koniec, warto przejrzeć dobre materiały edukacyjne dotyczące certyfikacji Agile.