Jednym z elementów właściwych dla dobrze funkcjonujących zespołów inżynieryjnych jest samodzielna organizacja. W takim zespole role i obowiązki są wyraźnie wyznaczone, a jego członkowie zobowiązują się dostarczyć projekt według dobrze przemyślanego planu.
W zeszłym roku utworzyliśmy nowy zespół o nazwie Micros Scale, który koncentruje się na utworzeniu nowej wewnętrznej platformy jako usługi (PaaS) Atlassian, która będzie środowiskiem naszych programistów. Nasza praca ma konkretny zakres i wyraźnie wyznaczone ramy czasowe, dlatego z większym zaangażowaniem realizowaliśmy prace w sposób przyrostowy, byliśmy bardziej skoncentrowani, ukierunkowani na cel i proaktywni.
Jednak wcześniej nasz zespół otrzymywał mnóstwo doraźnych prac związanych z eksploatacją, które uniemożliwiały nam prawidłowe zaplanowanie sprintów. Co najmniej 55 procent potencjału wykonawczego zespołu pochłaniało rotacyjne utrzymywanie dostępności zasobów. W związku z tym wówczas najlepsza była dla nas metodyka Kanban.
Warto zauważyć, że zgodnie z modelem Tuckmana zespół Micros Scale był na etapie formowania, a kilka obszarów, takich jak planowanie potencjału wykonawczego, planowanie sprintów, wyznaczanie celów, refleksje w zespole, dopracowywanie i przygotowywanie historyjek, szacowanie, dzielenie projektu itp. wymagało poprawy.
Która metodyka Agile była dla nas odpowiednia?
W Micros Scale funkcjonują dwa główne, wysoce złożone projekty, których termin realizacji został publicznie podany klientom. To oznacza, że niezwykle ważne jest, aby dostarczyć je szybciej. Potrzebowaliśmy niezawodnego podejścia do dostarczania i chcieliśmy popracować nad naszym planowaniem, jak prawdziwi profesjonaliści Agile. Chcieliśmy, aby nasz zespół samodzielnie organizował swoją pracę, osiągał wspólne cele i działał empirycznie.
Poddaliśmy nasze podejście Agile ocenie, zadając sobie następujące pytania:
- Czy da się ustalić cel każdej iteracji, aby dostarczyć docelowy obiekt o unikatowym motywie?
- Czy jesteśmy w stanie zobowiązać się do dostarczenia konkretnego zakresu wyników w ciągu tygodnia lub dwóch?
- Czy jesteśmy w stanie opracować wymagania, nad którymi musimy pracować, i się ich trzymać?
- Czy częstotliwość doraźnych wniosków o zmianę priorytetów zadań jest niska i czy prawdopodobieństwo wprowadzania drastycznych zmian jest mniejsze?
- Czy nasz zespół dopiero zaczyna przygodę z procesami Agile i jeszcze nie osiągnęliśmy w tym zakresie dojrzałości?
Odpowiedzi na te pytania były twierdzące, dlatego zdaliśmy sobie sprawę, że Scrum to najlepsza metodyka Agile dla naszego zespołu. Oto dodatkowe informacje, które wykorzystaliśmy do podjęcia świadomej decyzji:
| | | | |
|---|---|---|---|
| Metodyka Agile | O co w niej chodzi? | Czy to nam pomaga? | Dlaczego? |
| Scrum | Metodyka Scrum opiera się na przejrzystym harmonogramie i fragmentach prac o ustalonych priorytetach, natomiast metodyka Kanban bazuje na wizualizowaniu pracy przydzielanej zespołowi doraźnie. | Tak | Mamy przejrzysty, wstępnie zdefiniowany backlog, który wymaga doprecyzowania i ustalenia priorytetów. Nasza praca jest przewidywalna, natomiast poprzednim zespole było wiele niespodzianek i wniosków o wysokim priorytecie. |
| Historyjek nie powinno się zmieniać w trakcie sprintu. | Tak | Możemy przyjąć bardziej elastyczne podejście — w tym przypadku Scrumban (hybrydowe połączenie metodyk Scrum i Kanban). | |
| Metodyka Scrum jest łatwiejsza do wdrożenia dla zespołów Agile, które wciąż uczą się kierowania pracą w oparciu o funkcje. Scrum ma bardziej nakazowy charakter, uwzględnia rytuały i przedziały czasowe, które wyznaczają konkretne ramy. | Tak | Mamy nowy zespół składający się z nowych członków, wciąż jeszcze na etapie tworzenia i docierania się, dlatego Scrum pomaga nam osiągnąć większą dojrzałość. Zapoznaj się z modelem Tuckmana. | |
| Kanban | Ograniczenie liczby prac w toku i koncentracja na skróceniu czasu cyklu projektu. Ma zastosowanie w przypadkach, gdy zespół nie ma ograniczenia czasowego co do wykonania prac ani osi czasu, której zobowiązał się dotrzymać. Wnioski napływają do zespołu, który jak najszybciej się nimi zajmuje (jak w przypadku umów SLA w zespołach centrum obsługi). | Nie | Inne zespoły są od nas zależne, więc potrzebujemy szacunkowych ram czasowych, aby ułatwić innym planowanie z uwzględnieniem naszych postępów. Niektóre z naszych zobowiązań są udostępniane publicznie klientom Atlassian, dlatego musimy być uważni i dobrze je zaplanować. Nie mamy wielu wniosków wymagających obsługi w krótkim czasie, jak w centrum obsługi. |
| Doskonałe rozwiązanie dla zespołów, które obsługują wiele przychodzących wniosków operacyjnych o różnym priorytecie i różnej wielkości. | Tak | Nie mamy dużego obciążenia wynikającego z konieczności utrzymania dostępności zasobów, a za zarządzanie strumieniem prac odpowiada jednoosobowa rola w zespole zajmowana rotacyjnie. Jeśli chcemy, możemy wykorzystać na potrzeby tej odrębnej roli metodykę Kanban. |
Wdrożyliśmy metodykę Scrum
Mam pełną świadomość, że przywództwo jest jedną z głównych cech menedżerów ds. technicznych, podobnie jak pełnienie funkcji łącznika, kompasu i trenera. Muszę więc rozwijać wszystkie kompetencje przywódcy równocześnie. Cel ten udało mi się osiągnąć dzięki przestrzeganiu poniższych zaleceń.
Dowiedz się więcej o metodologiach Agile
Wewnętrzne zasoby edukacyjne firmy Atlassian pomogły mi zwiększyć umiejętności w zakresie praktyk Agile. Ukończyłam obszerne szkolenia z metodyki Agile i konsultowałam się z trenerem Agile. Przeprowadziłam rozmowy z kilkoma menedżerami ds. technicznych, aby zapoznać się z ich doświadczeniami zdobytymi w innych organizacjach i zespołach.
Korzystaj z modelu DACI
Model podejmowania decyzji DACI, będący skrótem od angielskich słów Driver, Approver, Contributors i Informed, oznaczających odpowiednio osobę kierującą, osobę zatwierdzającą, osoby uczestniczące oraz osoby informowane, wykorzystaliśmy do podejmowania najbardziej efektywnych i wydajnych decyzji grupowych. Omówiłam z zespołem propozycję zmiany wg DACI, aby poznać ich uwagi oraz uzyskać zgodę i wsparcie.
Skorzystaj z szablonu sprintu
Opracowałam proces zarządzania naszymi sprintami i utworzyłam szablon dla poszczególnych sprintów, aby ułatwić bardziej rozsądne planowanie. Szablon planowania sprintu uwzględniał następujące zagadnienia:
- Jak przeanalizować poprzedni sprint, aby wyraźnie ustalić, co udało się osiągnąć, a następnie to uczcić?
- Jak przeprowadzić retrospektywną refleksję na temat poprzedniego sprintu i zastosować wnioski do kolejnego.
- Czym są kadencja, nazwa, cele ogólne i cele szczegółowe sprintu?
- Ile historyjek zobowiązujemy się dostarczyć? Jaki jest zakres sprintu?
- Jak planować potencjał wykonawczy z uwzględnieniem dostępności poszczególnych osób?
- Jakie działania musimy podjąć w połowie sprintu, aby w pełni przygotować się do kolejnego?
- Jak pisać historyjki, opracowywać wymagania oraz tworzyć rozwiązania, które pozwolą je zrealizować?
- Jak śledzić stan historyjek, które zobowiązaliśmy się zrealizować, i co zrobić z nieukończonymi historyjkami?
Mamy również świetny samouczek dotyczący przeprowadzania sprintów w Jira Software.
Przejście na Scrum okazało się strzałem w dziesiątkę
Przechodząc na Scrum, wprowadziliśmy poniższe ulepszenia:
Poprawa prędkości
W metodologiach Agile jednym z czynników wykorzystywanych do pomiaru produktywności zespołu jest prędkość, czyli przeciętna ilość pracy realizowana przez zespół Scrum w trakcie sprintu. Wykres prędkości pozwala nam śledzić zobowiązania podjęte przez zespół oraz dostarczane wyniki. Na poniższym wykresie prędkości szary słupek odpowiada liczbie punktów historyjek, jakie zespół zobowiązał się zrealizować, biorąc pod uwagę swój potencjał wykonawczy. Jest wyświetlany w zestawieniu z niebieską kolumną, która wskazuje liczbę faktycznie dostarczonych punktów historyjek. Na podstawie takiego wykresu zespół może korygować prognozy dotyczące przyszłych sprintów.
Wczesne rozpoznawanie ryzyka
Możliwość wczesnej identyfikacji zagrożeń i opracowania proponowanego rozwiązania jest kluczem do sukcesu projektów.
Definiując cele i motywy sprintu, wybraliśmy spójne historyjki do osiągnięcia tych celów. W trakcie sesji w środku sprintu nasz zespół doprecyzował, zawęził i szczegółowo opracował historyjki. Opracowując historyjki, zadawaliśmy sobie następujące pytania:
- Co należy zrobić?
- Dlaczego wykonujemy tę pracę?
- Jaką wartość biznesową przyniesie wykonanie tej pracy?
Ułatwiło to naszym inżynierom rozpoznanie zależności i priorytetowe potraktowanie zgłoszeń, które mają większy wpływ na eliminowanie przeszkód. Doprowadziło to również do zmiany naszego sposobu pracy i większego skupienia uwagi zespołu na konkretnym projekcie.
Czas na świętowanie! Dostarczyliśmy, co trzeba
Planowanie potencjału wykonawczego i wyznaczanie celów przełożyły się również na istotne zwiększenie naszej motywacji i podjęcie wyzwania, jakim jest zapewnienie przejrzystości naszych zobowiązań. Pomyślnie dostarczyliśmy jedną krytyczną fazę shardingu kont PaaS Atlassian. Już wkrótce dostarczymy również pierwszą fazę naszego projektu dotyczącego miejsca przechowywania danych, aby uwzględnić więcej regionów AWS i zapewnić tym samym większą niezawodność, odporność oraz zgodność z przepisami.
Przejście od formowania do normowania
Jak już wspomniałam powyżej, zespół Micros Scale jest stosunkowo nowy i według modelu Tuckmana wciąż jest na etapie formowania.
Zdefiniowanie jednolitego celu dla zespołu zainspirowało wszystkich do dostosowania się i wspierania siebie nawzajem, aby osiągnąć cele zespołowe i zwiększyć motywację zespołu. Ponosiliśmy porażki, dokonywaliśmy refleksji, wyciągaliśmy wnioski i wdrażaliśmy usprawnienia. Po trzech i pół miesiąca zwiększyliśmy zatrudnienie w zespole Micros Scale o 50 procent i wciąż mogę z dumą stwierdzić, że jesteśmy zespołem w fazie normowania.
Poprawa komunikacji
Opracowanie planu i zaangażowanie w każdy sprint zwiększyło widoczność planowanych prac dla całego zespołu i doprowadziło do tego, że wszyscy mówimy tym samym językiem. Menedżerom ds. technicznych i interesariuszom jest znacznie łatwiej śledzić czynniki wstrzymujące projekt oraz postępy.
Jak dobrać własną metodykę Agile
- Nie wahaj się, czy weryfikować swoje procesy, gdy dostrzegasz problem. Myśl w sposób właściwy dla modelu Agile: ludzie, procesy i narzędzia.
- Przeanalizuj projekt i obowiązki zespołu, aby dobrać metodykę Agile, która najlepiej sprawdzi się w jego przypadku. Zapoznaj się z naszą stroną z porównaniem metodyk Kanban i Scrum, aby dowiedzieć się więcej na ich temat.
- Jeśli zdecydujesz się przejść na Scrum, polecam skorzystanie z tablicy Scrum Jira, utworzenie szablonu w Confluence lub w innym ulubionym narzędziu.
Dla każdego sprintu utwórz stronę planowania sprintu, aby przeanalizować i przemyśleć ostatni sprint, a następnie zaplanować kolejny, biorąc pod uwagę potencjał wykonawczy zespołu oraz cel sprintu. Mój prywatny szablon Confluence wygląda tak:
To z kolei mój szablon planowania potencjału wykonawczego będący elementem ogólnego szablonu Scrum:
A to mój szablon celów i zakresu sprintu:
W połowie sprintu dobrze jest przygotować kolejną stronę do śledzenia wyników zespołu z zeszłego tygodnia, historyjek, które trzeba przerzucić do kolejnego sprintu, biorąc pod uwagę postępy bieżącego (co nazywamy porządkowaniem), a także opracowania (doprecyzowania) uporządkowanych historyjek. Tak wygląda mój szablon porządkowania i doprecyzowania backlogu na półmetku sprintu:
Każdy zespół jest inny, a rozwiązania, które sprawdziły się u nas, mogą nie być odpowiednie dla innych zespołów. Lepszą metodyką może być Scrum, Kanban, a nawet ich hybryda, jak Scrumban czy Kanplan. Najważniejsze, aby ocenić konkretne potrzeby zespołu i ustalić, jaka metodyka sprawdzi się w jego przypadku.
