W miarę jak firmy przenoszą rozwiązania programowe z rozwiązań lokalnych do chmurowych, często stawiają sobie za cel osiągnięcie większej „elastyczności”. W idealnym przypadku powinno to mieć zastosowanie do wszystkiego na poziomie międzyfirmowym. I oczywiście wszędzie w tym samym czasie.
Transformacja procesów mogłaby być łatwo możliwa, przynajmniej w teorii. Możesz zdefiniować ceremonie scrumowe i ponownie przypisać ludzi do nowych ról (takich jak mistrzowie scrumowi, właściciele produktu, menedżerowie dostaw i zespoły scrumowe).
Możesz zabrać ze sobą narzędzia takie jak Jira, Azure ADO i Miro Board i uczynić je obowiązkowymi. A co z procesami łączącymi narzędzia w całość? A co z transformacją ludzkich umysłów, zachowań i sposobów pracy? Staje się jasne, że nie przejdą one gładko i nie zakończą się szybko. Teraz przyjrzyjmy się dlaczego.
Spis treści:
Co to jest inicjatywa na rzecz transformacji dostaw i dlaczego firmy ją podejmują?
Ogromna część współczesnych firm nadal działa w oparciu o model dostaw kaskadowych. Oznacza to, że:
Cały ten proces może zająć od kilku miesięcy do kilku lat i jak widać, wyniki użytkownicy zobaczą dopiero pod koniec tego procesu. Tak więc po długim oczekiwaniu nadchodzi moment prawdy (lub porażki).
Jeśli w ciągu tego długiego czasu coś się zmieni i produkt końcowy powinien wyglądać nieco inaczej, mamy do czynienia z sytuacją zwaną prośbą o zmianę. Projekt należy ponownie otworzyć, przerobić i ponownie zatwierdzić. Przedłuża cały harmonogram zajęć o kolejną część.
Oczywiście nie jest to w żaden sposób zwinne. Każda zmiana wymaga wcześniejszego ponownego uruchomienia całego procesu.
Przejście na Agile
Jak zatem wyjść z tej sytuacji i zmienić ją na zwinną? Ludzie pracują przy wodospadzie przez wiele lat, a nawet stuleci. Mają role i obowiązki, z którymi czują się komfortowo i nie chcą zmieniać status quo. Głównym powodem jest to, że dokonanie tej zmiany ostatecznie oznacza utratę części mocy, którą posiadali do tej pory.
To jest główny powód, dla którego taka zmiana wywołuje u ludzi największy poziom oporu, jaki możesz stworzyć.
#1. Restrukturyzacja zespołu
Pierwszą i stosunkowo najprostszą metodą jest restrukturyzacja ludzi w zespoły scrumowe. Podziel je na podstawie obszarów funkcjonalnych lub innego logicznego podziału, który ma sens.
Podział zwykle przebiega gładko; problem zaczyna się, gdy zdasz sobie sprawę, że ludzie nadal są przywiązani do oryginalnych struktur. Nawet jeśli są już częścią nowych zespołów scrumowych, w praktyce tak nie jest. Nadal pracują na starym układzie, ponieważ nadal mają obowiązki, które nie zakończyły się wraz z procesem restrukturyzacji zespołu (bo dlaczego tak miałoby być – przywództwu nie zależy zbytnio na tym, co należy zakończyć, ale przede wszystkim na tym, co trzeba zacząć).
W praktyce więc powstaje zespół scrumowy, który nie jest w pełni dedykowanym zespołem scrumowym. To grupa ludzi, która ma teraz po prostu więcej pracy do wykonania. Wewnątrz zespołu scrumowego nie ma tak dużo czasu na pracę, jak oczekuje tego kierownictwo.
Jednocześnie oczekuje się, że ludzie zakończą swoje pierwotne działania, a także to nowe oczekiwanie w zespołach scrumowych. To konfiguracja, która już na początku jest zdecydowana zawieść.
#2. Planowanie ceremonii Scrum
Nakazanie zespołom planowania kilku regularnych rozmów telefonicznych (ceremonia sprintu) jest łatwe do zdefiniowania i rozpoczęcia. Przynajmniej zakładając, że Twoje zespoły scrumowe nie składają się z osób z co najmniej 3 stref czasowych (co często ma miejsce).
Problem zaczyna się, gdy ludzie nie chcą regularnie uczestniczyć w ceremoniach. W zależności od tego, kto zaginął i jak często, może to przerodzić się w różnego rodzaju problemy. Na przykład:
- Jeśli właściciele produktu nie będą obecni na ceremoniach planowania i udoskonalania, zespół nie będzie miał żadnych nowych historii do pracy. Lub opis historii jest tak ubogi, że reszta zespołu nie może zacząć nad nimi pracować.
- Jeśli na rozmowach brakuje mistrzów scrumów, zespołowi brakuje podstawowej orkiestracji scrumowej i z czasem może się on zgubić.
- Jeśli często brakuje członków zespołu programistów, nie mogą się ze sobą synchronizować, a komunikacja wewnątrz zespołu jest znacznie trudniejsza. Ponadto, aby nadrobić zaległości, potrzeba więcej spotkań, co zabiera zespołowi kolejny czas.
Ostatecznie niekoniecznie jest to wina ludzi, że opuszczają ceremonie. Tyle że konfiguracja nie pozwala im na prowadzenie rozmów (patrz wyżej o równoległych poprzednich zadaniach).
#3. Stabilność zespołu
Możesz mieć zespół scrumowy ze strukturą i ceremoniami, ale jeśli ten zespół nie będzie stabilny przez dłuższy okres czasu – powiedzmy idealnie przez co najmniej pół roku, moim osobistym minimalnym wymaganiem będzie rok stabilności – wtedy taki zespół może tak naprawdę nie ewoluują i nie udoskonalają się.
Następnie prawdopodobnie nigdy nie dotrzesz do w pełni niezależnego zespołu scrumowego, który jak zwykle radzi sobie ze sprintami. Wreszcie, będziesz musiał stale kształcić i uczyć się ludzi w zespole, aby zrozumieć sposób myślenia i procesy scrumowe. To wyczerpujący problem.
Jest to problem bardzo niedoceniany, szczególnie przez kierownictwo lub kierownictwo firmy. Nazywanie zespołów ludzkich po prostu „zasobami” i planowanie ich „wykorzystania” z kwartału na kwartał to błyskawiczna droga do piekła.
#4. Nowe role dla tych samych ludzi
Kolejną przeszkodą do pokonania jest przydzielanie istniejących osób do innych, nowych ról. Ci, którzy wcześniej zarządzali zespołami z najwyższą mocą, mogą teraz zostać na przykład właścicielami produktu. Jest to mocna pozycja w zespole scrumowym, jednak można ją postrzegać jako słabszą rolę w stosunku do istniejącej konfiguracji.
Nagle właściciele produktów muszą zsynchronizować się ze scrum masterem lub menedżerami programów. Nadal są odpowiedzialni za treść, ale nie tak bardzo za procesy dostarczania. Taka sytuacja wymaga rezygnacji z pewnych obowiązków, które wcześniej spoczywały na ludziach i dlatego są trudne do przełknięcia.
#5. Sposoby pracy
To jest ciekawe i słyszę to od czasu do czasu dość często – musimy nauczyć się nowych sposobów pracy, aby stać się istotnymi na rozwijającym się rynku, gdzie podstawowym oczekiwaniem jest elastyczność. Ale co dokładnie oznaczają te sposoby pracy?
Jeśli mnie zapytasz, jasne jest, co kierownictwo ma na myśli – osiągnąć (znacznie) więcej w krótszym czasie. Po utworzeniu zespołów scrumowych oczekuje się, że każdy członek zespołu nagle z dnia na dzień osiągnie udokumentowane, przyrostowe wyniki. Jeśli tak nie jest, kierownictwo zacznie zadawać sobie pytanie, dlaczego zwinny proces nie działa dobrze.
Zupełnie nie wiadomo skąd kierownictwo oczekuje, że liczy się każda godzina i że zespoły scrumowe w zasadzie nie będą miały czasu na bezczynność tylko dlatego, że prawdopodobnie nie ma na to miejsca, aby wszystkie procesy scrumowe miały miejsce. I tak w skrócie można zdefiniować „nowe sposoby pracy” z perspektywy przywództwa.
Oczywiście to oczekiwanie nie opiera się na ocenie rzeczywistości. Iluzją jest oczekiwanie, że ludzie w firmie zaczną pracować więcej w tym samym okresie tylko dlatego, że ulegną zmianie niektóre codzienne procesy. To znaczy, niektórzy z nich mogliby, nawet jeśli byłaby to mniejszość. Jednak nawet ta grupa ulega dalszemu ograniczeniu poprzez zaśmiecanie ich większą liczbą zadań jednocześnie.
Różnica między celem a rzeczywistością
Nie ma wątpliwości, że opis celu końcowego jest często dobry i ma wiele sensu. Opiera się na następujących zasadach:
- Ustabilizowane zespoły scrumowe pracujące na niezależnych backlogach z jasnymi KPI i OKR.
- Właściciele produktów mogą tworzyć solidne plany działania i planować treści według priorytetów, które będą dostarczane zgodnie z konkretnymi harmonogramami.
- Zdefiniowana zawartość zaległości z odpowiednimi funkcjami została już wyszczególniona przed rozpoczęciem pracy.
- Niezawodne procesy testowe realizowane równolegle z regularnymi pracami programistycznymi w sprincie.
- Regularne wypuszczenia na produkcję – przynajmniej raz w miesiącu, a najlepiej po każdym zakończeniu sprintu.
- Śledzenie ryzyk i problemów oraz komunikacja pomiędzy różnymi zespołami scrumowymi w przypadku zależności.
Jeśli chodzi o rzeczywistość, mogę stwierdzić, że żaden z powyższych punktów nie jest łatwy do osiągnięcia.
- Tworzysz zespoły scrumowe, ale one ciągle się zmieniają (z kwartału na kwartał). Inwestujesz czas, aby nauczyć zespół procesów scrumowych, a gdy w końcu zaczną to akceptować i zmieniać sposób pracy, reorganizujesz zespoły na kolejny okres. Plany drogowe są modyfikowane, przesuwane lub anulowane.
- Właściciele produktów nie mają zielonego pojęcia o szczegółach planu działania i (tylko dlatego, że mieli już takie przyzwyczajenia) będą przydzielać swoje zadania budowania zawartości backlogu bezpośrednio zespołowi. W rezultacie zespół nie ma czasu na opracowywanie treści, ponieważ najpierw musi dowiedzieć się, co rozwinąć.
- Procesy testowania są wyłącznie ręczne i wymagają wielu podetapów, zatwierdzeń oraz skomplikowanych procesów. Oznacza to, że testowanie nie może zakończyć się w tym samym sprincie, co programowanie.
- W rezultacie wypuszczenie do produkcji jest opóźnione o kilka sprintów.
- Komunikacja pomiędzy różnymi zespołami scrumowymi jest chaotyczna i nieefektywna, ponieważ każdy zespół ma do wykonania wiele działań w każdym sprincie. W rzeczywistości właściciele produktów mają tendencję do przypisywania zespołowi zbyt dużej ilości treści w każdym sprincie. Zespół nie ma szans na ukończenie wszystkiego, dlatego cały czas żyje pod presją terminów.
Korygowanie błędów
Mając doświadczenie z kilku projektów transformacji zwinnych, chciałbym podsumować niektóre z największych błędów, jakich doświadczyłem i przedstawić kilka subiektywnych opinii na temat możliwości ich przezwyciężenia.
#1. Właściwe obowiązki i właściwe role
Jeśli spróbujesz nagiąć definicję i rozłożyć obowiązki w inny sposób niż powinien w przypadku scrum/agile, cała inicjatywa zakończy się niepowodzeniem.
- Właściciele produktów są właścicielami treści i utrzymują zaległości. Są odpowiedzialni za zaległości i jeśli historie zaległości nie są dobrze zdefiniowane, to do nich należy podjęcie działań i naprawienie tego. Z drugiej strony nie powinni mieć żadnego wpływu na przydzielanie zadań osobom w zespole scrumowym czy decyzje dotyczące budżetu projektu.
- Scrum masterzy nie ponoszą żadnej odpowiedzialności za zawartość backlogu. Ich zadaniem jest koordynowanie ceremonii i edukowanie zespołu w zakresie sprawnego sposobu pracy. Nie powinni być sekretarzami Właścicieli Produktu. Wręcz przeciwnie, mają chronić zespół programistów przed właścicielem produktu i interesariuszami zewnętrznymi.
- Każdy zespół scrumowy powinien mieć przypisanego lidera dostaw. Ta osoba połączy PO, SM i zespół programistów w wykonalną konfigurację, zdefiniuje procesy dostawy i rozwiąże wszelkie potencjalne ryzyko, problemy lub konflikty, jakie może mieć zespół. Lider dostawy to właściwa osoba, która może decydować o kwestiach kadrowych i budżetowych projektu. Osoba ta powinna dążyć do zbudowania środowiska dla zespołu, w którym każdy może dawać z siebie wszystko.
- Zadaniem zespołu programistów jest opracowanie historii z backlogu. Mogą pomóc PO w tworzeniu treści dla niektórych historii (głównie tych, które są zbyt techniczne), ale nie są odpowiedzialni lub nawet nie są odpowiedzialni za historie tworzące treść planu działania.
#2. Stabilny zespół
Inwestowanie w sprawną edukację zespołu jest ważne i musi być procesem szybkim. Pozostawianie tej wiedzy na marginesie co kilka miesięcy jest dla wszystkich stratą czasu.
Pierwsze pięć sprintów możesz wykorzystać jako krzywą uczenia się dla zespołu, aby poznać i przećwiczyć podstawowe działania scrumowe. Gdy staną się one jasne dla całego zespołu, można rozpocząć proces ciągłego doskonalenia zespołu scrumowego. Jeśli jednak osoby w zespole będą się regularnie zmieniać, znajdziesz się w ciągłej pętli transferu wiedzy i edukacji.
Taki zespół prawdopodobnie nigdy nie osiągnie pełnego potencjału wydajnościowego, a kadra kierownicza w dalszym ciągu będzie się zastanawiać, dlaczego wcześniej (przed transformacją zwinną) był bardziej wydajny, niż się teraz wydaje.
Zbuduj więc zespół, zainwestuj wiedzę, a gdy zespół nabierze pewności co do nowych procesów, po prostu zachowaj go tak, jak jest i rozwijaj się dalej. Odtąd rozpocznie się nieustanna droga do doskonałości.
#3. Matryca RACI
Dobrą praktyką jest zbudowanie i uzgodnienie matrycy RACI (odpowiedzialny, odpowiedzialny, konsultowany, poinformowany) pomiędzy wszystkimi zespołami tuż przed rozpoczęciem prawdziwej pracy. Może to potencjalnie wyeliminować wiele zamieszania już na początku.
Jest to dość istotne, zwłaszcza na wczesnych etapach inicjatyw transformacyjnych. W przeciwnym razie ludzie zaczną zadawać pytania dotyczące tego, kto i co powinien zrobić w jakiej sytuacji, zwłaszcza w tych, które nie zostały wyraźnie poruszone w komunikacji zespołu.
Oto przykład takiej macierzy RACI dla niektórych obowiązków. Twój projekt może mieć inny zestaw. Ważne jest, aby uchwycić odpowiednie.
Osoba zgłaszająca zadanieKierownik dostawyWłaściciel produktuScrum MasterZespół deweloperówSesje planowania sprintuC/ICA/IRC/IDPrzyrost wersji dostawyN/AIA/IC/IRSPrzegląd wydrukuC/IIRICSRetrospektywa drukuIIA/IRC/IRSprawdź zaległościIA/IRAC/I
Wniosek
Byłoby jeszcze o czym pisać, ponieważ jest wiele sposobów i wiele miejsc, w których zwinna transformacja może sprowadzić z toru. Celem było zwrócenie uwagi na niektóre problemy, które moim zdaniem często się powtarzają.
Sama inicjatywa jest dobrym pomysłem. Jednakże, jeśli będziesz przestrzegać kilku podstawowych zasad, szybko może to stać się koszmarem dla wszystkich uczestników. Podkreśliłem kilka z nich, ale kieruj się zdrowym rozsądkiem, a wszystko będzie dobrze. 🙂
Następnie przejrzyj dobre zasoby edukacyjne dotyczące certyfikacji Agile.