Zdecydowanie zbyt często firmy ruszają z misją „przejścia na model Agile”, zanim tak naprawdę zrozumieją, co to oznacza. Zaczynają się piętrzyć trudności, a efekt nie spełnia oczekiwań, przez co każdy zaczyna kwestionować wartość samego „przejścia na model Agile” — drastycznie zmniejszając swoje szanse na faktyczne dokonanie takiego przejścia.
Prawda jest taka, że przejście na model Agile pozwoli zwiększyć produktywność zespołów i przyspieszyć dostarczanie projektów, jednak tylko wtedy, gdy każdy zgodzi się na zasady modelu. Dołącz do dyskusji prowadzonej przez Heather Fleming i Justina Riservato z firmy Gilt będącej prawdziwym gigantem w sektorze e-commerce na temat przyczyn, ze względu na które osiągnięcie konsensusu co do zasad metodyki Agile jest ważniejsze niż samo wdrożenie procesu.
Heather i Justin przede wszystkim starają się odpowiedzieć na trzy kluczowe pytania, jakie każdy zespół musi sobie zadać, zanim wkroczy na ścieżkę wdrożenia metodyki Agile:
- „Ale kiedy właściwie skończysz?” Dlaczego wyzbycie się koncepcji terminów jest najważniejszym (i najtrudniejszym) zagadnieniem do omówienia przy przechodzeniu na model Agile.
- „To dla mnie priorytetowa sprawa, ale mogę spotkać się z Tobą dopiero w przyszłym tygodniu”. Co zrobić, gdy Twój partner biznesowy nie może (lub nie chce) być w pełni zaangażowanym członkiem zespołu.
- „Chcę po prostu pisać kod. Dlaczego muszę uczestniczyć w tych wszystkich spotkaniach?” Dlaczego wdrożenie metod Scrum nie jest pierwszym etapem do wprowadzenia modelu Agile?
Oglądaj i ucz się
Pytania i odpowiedzi
Heather i Justin zebrali tutaj niektóre ważne pytania z sesji pytań i odpowiedzi do tej prezentacji. Czytaj dalej, aby lepiej zgłębić taktyki stosowania metodyk Agile.
P1: Cyfrowa czy fizyczna tablica Agile? Co o nich sądzicie?
O1: To naprawdę zależy od organizacji zespołu. Czy wszyscy pracujecie w jednym miejscu? Jak duży jest zespół? Czy macie miejsce na wielką, fizyczną tablicę? W Gilt stosowaliśmy obydwa rodzaje tablic, jednak stwierdziliśmy, że w miarę rozwoju firmy, gdy powstawały dziesiątki zespołów, tablice Agile w systemie JIRA Software były bardziej praktyczne od tablic fizycznych. Łatwiej je skonfigurować i wprowadzać w nich zmiany. Łatwiej również udostępnić je członkom zespołu pracującym zdalnie. Niewątpliwą zaletą tablic fizycznych jest to, że nie da się ich po prostu zignorować, ponieważ masz je przed oczami. Są również świetnym miejscem do prowadzenia spontanicznych dyskusji na temat bieżących spraw albo spotkań stand-up jeśli je organizujecie.
P2: Jak można współpracować z menedżerem lub klientem, który nie przestrzega zasad lub nie rozumie procesu Agile? Czasami czuję się, jak marny trener przepływów pracy.
O2: Ważne, aby zastanowić się nad kolejnością operacji. Jeśli próbujesz realizować proces Agile z ludźmi, którzy w niego nie wierzą, wówczas przypomina to wyjście przed szereg. Aby miało to szansę zadziałać, najważniejsze jest wypracowanie konsensusu na poziomie samej filozofii, zanim przystąpi się do praktycznej realizacji procesu. Dawniej robiliśmy to, przyglądając się konkretnym problemom, jakie zespół miał z bieżącym procesem, i rozwiązując je zgodnie z metodyką Agile. Czy jesteś w stanie przeprowadzić swojego menedżera lub klienta przez proces rozwiązania rzeczywistych problemów, z którymi się borykają? Jak podejdziesz do tych problemów zgodnie z zasadami modelu Agile? Czy jesteś w stanie stopniowo wprowadzać te osoby w metodykę Agile, zamiast wymuszać całkowitą zmianę całego procesu? Wówczas możesz zacząć zwracać ich uwagę na rzeczywiste wyniki, stopniowo, w miarę jak zespół staje się coraz lepszy. Krótko mówiąc, wykorzystaj metodykę Agile do przejścia na model Agile. ;)
P3: Jak wdrażać proces Agile, gdy projekt ma ustalony budżet i/lub harmonogram oraz konkretną listę wymagań do wdrożenia?
O3: Po pierwsze nie da się pomyślnie zrealizować projektu w oparciu stały harmonogram oraz stałą listę wymagań do wdrożenia, dlatego należy zadać sobie pytanie, czy można przekonać wszystkich, że taki scenariusz pozostaje w krainie fantazji. Większość ograniczeń dotyczących terminów oraz wymagań nie jest ograniczeniami tak naprawdę, a jedynie życzeniami. Zacznij od przedyskutowania, dlaczego w ogóle wykonujecie prace albo jaki problem próbujecie rozwiązać. Jeśli faktycznie zrozumiesz cele projektu oraz przyczyny ograniczeń, będziesz w stanie zapewnić, aby zespół wykonywał właściwe prace w odpowiednim czasie. Sporządzenie listy wszystkich wymagań i opatrzenie ich datami nie sprawi magicznie, że wszystko zostanie zrealizowane na czas.
P4: Do większości projektów przypisana jest datę wydania, o której zazwyczaj informuje się partnerów i klientów. W tym scenariuszu jedyną rzeczą podlegającą negocjacji jest zestaw funkcji (choć odbywa się to kosztem jakości). Jak radzicie sobie z ograniczeniami związanymi z ostatecznym terminem?
O4: Naszym zdaniem odpowiedź kryje się w samym pytaniu — trzeba negocjować zakres. Jeśli tego nie zrobić, faktycznie ucierpi na tym jakość. Założenie, że uda Ci się wykonać całość zakresu bez względu na wszystko, jest nierealistyczne — musisz zapewnić zespołom możliwość pracy w realnych ramach, nawet jeśli nie to ludzie chcą usłyszeć. Heather napisała na ten temat krótki wpis na blogu, który możesz tutaj przeczytać.
P5: Jakie zmiany w sposobie wdrażania metodyki Scrum należałoby wprowadzić Waszym zdaniem?
O5: Jednym z największych problemów, jakie upatrujemy w metodyce Scrum, jest jej sztywność. Oczekiwanie że pojedynczy proces zawierający zbiór ściśle określonych zasad sprawdzi się we wszystkich zespołach, niezależnie od tego, nad czym pracują, i kim są ich członkowie, jest butne. Mieliśmy do czynienia z zespołami, w których ta metodyka się sprawdzała, jednak Scrum nie jest jedynym sposobem realizacji zasad Agile, a wielu zespołom nie udaje się wdrożyć modelu Agile, ponieważ uważają, że muszą stosować metody Scrum w tej specyficznej formie, z uwzględnieniem wszystkich zalecanych ról, historyjek użytkowników, kryteriów akceptacji, spotkań i artefaktów. Heather nie do końca podoba się również tytuł „Scrum Master”. ;)
P6: Jak można uniemożliwić interesariuszom wywieranie bezpośredniego wpływu na członków zespołu?
O6: Szczerze mówiąc, dobry interesariusz w istocie JEST członkiem zespołu. Najlepszym rozwiązaniem jest zaangażowanie kluczowego interesariusza w działania zespołu, aby wszyscy pracowali razem. Jeśli masz do czynienia z interesariuszami, którzy po prostu przerzucają kolejne prace na Twój zespół albo dokładają prace w trakcie trwania projektu i próbują wszystko zmieniać, ważne jest, aby cały zespół wiedział co i dlaczego robi. Dzięki temu interesariusze będą zawsze spotykali się z tą samą odpowiedzią, bez względu na to, z kim będą rozmawiać. To właśnie sprawia, że zespół faktycznie jest zespołem, a nie tylko zbiorowością jednostek. Musicie się komunikować — i to dużo — i dbać o to, aby każdy był na bieżąco i dążył do realizacji tych samych celów.
P7: Czy przy szacowaniu historyjek stosujecie przybliżone szacunki z dokładnością do rzędu wielkości (godzinowe) czy punkty?
O7: Korzystamy z jednego i drugiego sposobu, a niektóre zespoły wcale nie szacują. Punkty są świetnym rozwiązaniem, ponieważ są bardziej abstrakcyjne i nie są powiązane z żadnym konkretnym terminem w kalendarzu. Szacunki godzinowe mogą być pomocne na etapie przejściowym, gdy zespół opiera się szacowaniu, ponieważ mają one bardziej skonkretyzowany charakter. Istotą szacowania jest możliwość oceny, czy ilość prac przewidzianych na czas sprintu nie jest zbyt duża lub zbyt mała, oraz wprowadzenie odpowiednich korekt, jednak po rozpoczęciu sprintu naprawdę są one bezcelowe. Dochodzimy do wniosku, że po przepracowaniu z zespołem określonego czasu, proces szacowania staje się właściwie Możemy spojrzeć na prace i z łatwością stwierdzić, czy ich ilość jest odpowiednia do wykonania podczas sprintu.
P8: Jak bardzo cenicie kierowników/menedżerów projektów posiadających umiejętność dogłębnej analizy i znajomość produktu w porównaniu z tymi, którzy po prostu koordynują spotkania między interesariuszami technicznymi i biznesowymi w celu zebrania wymagań?
O8: Stawiamy praktycznie tylko na nich :). Koordynowanie spotkań, sporządzanie notatek itp. nie należy do specjalistycznych umiejętności. Każdy może to robić. Choć kwestie te są ważne, z pewnością nie stanowią najbardziej istotnego wkładu, jaki można wnieść w zespół. Jeśli zajmujesz się jedynie pracą administracyjną, wówczas zespół ma prawo zadać pytanie, dlaczego w ogóle do niego należysz. Każda osoba zajmująca się zarządzaniem projektami w Gilt posiada dogłębną znajomość zagadnień merytorycznych, oraz narzędzi i technik stosowanych do ich realizacji, i wnosi tę wiedzę do każdego zespołu, w którym pracuje. Wielu z nas pełniło wcześniej funkcje techników lub pracowało w innych działach firmy Gilt, co pozwala nam korzystać z unikalnej wiedzy specjalistycznej.
P9: Jak duże są zespoły w Gilt i jakie doświadczenie mają ich członkowie?
O9: Staramy się, aby nasze zespoły nie składały się z za wielu osób, ale były na tyle duże, aby zapewniało to samowystarczalność i realizację projektów bez zależności od innych zespołów. Przestrzegamy zasady „dwóch pizz”, która głosi, że zespoły powinny liczyć tylko tyle osób, ile można nakarmić dwoma pizzami. Żywimy również silne przekonanie, że każdy członek zespołu wnosi ze sobą zbiór unikalnych talentów i powinien mieć szansę wykorzystania tych talentów na rzecz zespołu, niezależnie od zajmowanego stanowiska. Jeśli więc tradycyjnie za wszystkie prezentacje odpowiadał product owner, ale okaże się, że kiepsko sobie z tym radzi, a mamy inżyniera, który świetnie opowiada historie i potrafi sobie zaskarbić serca publiczności, chętnie wykorzystamy ten talent inżyniera w zespole. Zajmowane stanowiska nie decydują o tym, jacy jesteśmy!
P10: Jak zarządzać odrębnym zespołem ds. zapewniania jakości, zwłaszcza gdy testy mogą wchodzić w skład innego sprintu niż prace programistyczne?
O10: To jedna z bardziej kontrowersyjnych kwestii w naszej firmie, ponieważ w Gilt nie mamy odrębnego zespołu ds. zapewniania jakości. Wierzymy w skuteczność zautomatyzowanych testów będących elementem procesu programowania i wdrażania. Zespoły odpowiadają za jakość tworzonego przez nie kodu. Jeśli masz czas i wiedzę, aby pisać kod, masz też czas i wiedzę, aby napisać testy, które będą go sprawdzać. Przerzucanie tego zadania na zespół ds. zapewniania jakości nigdy nie przynosiło u nas dobrych rezultatów i wymagało mnóstwa dodatkowej dokumentacji oraz czasu, aby zespoły te mogły przystąpić do pracy.
P11: Czy w sytuacji, gdy zespoły pracują nad kilkoma „produktami” równocześnie, dobrym rozwiązaniem będzie zebranie wszystkich menedżerów produktów razem w trakcie planowania sprintów, aby ustalili względne priorytety na poziomie obejmującym wszystkie produkty? A może macie jakieś inne pomysły?
O11: Przestańcie to robić! To nie zadziała. Zespół musi mieć własnego menedżera produktu, a nie pracować nad wieloma produktami dla wielu menedżerów produktów funkcjonujących poza zespołem. Osoba pełniąca funkcję kierownika zespołu powinna tutaj wystąpić i wyraźnie nakreślić metodykę ustalania priorytetów w zespole, wskazując, w jakiej kolejności zespół zajmie się realizacją prac, biorąc pod uwagę założenia tej metodyki. Wracamy tutaj do naszego stwierdzenia, że „przed rozpoczęciem procesu, musisz obrać metodykę postępowania”.
P12: Próbuję wdrożyć metodykę Agile w zespole ds. kreatywnych usług marketingowych. Mamy pewne elementy, które MUSZĄ być dostarczone w konkretnym terminie (projekt reklamy, która ma się ukazać w czasopiśmie). Jak wpasować tego rodzaju projekty w ramy Agile?
O12: Model Agile jest w stanie poradzić sobie z takimi ograniczeniami. To do zespołu należy ustalenie, co i do kiedy trzeba zrobić, a następnie odpowiednie zaplanowanie sprintów. Metodyka Agile powinna ułatwić dotrzymanie tych terminów, ponieważ zapewnia możliwość dostosowania priorytetów i zaplanowanych prac (zakresu) w każdym sprincie. Jeśli zaczniecie monitorować prędkość swoich działań, wkrótce będziecie w stanie stwierdzić, czy jesteście w stanie dotrzymać tych terminów czy nie — i nie zajmie to wiele czasu. Później już wszystko będzie zależało od zdolności dobrego kierownika zespołu do wynegocjowania tego, czego zespół będzie potrzebował do pomyślnej realizacji zadania.
P13: Czy zmienianie celów nie jest w rzeczywistości zmienianiem zakresu?
O13: Jest, jednak nie nazywamy tego „zmienianiem zakresu” ponieważ chcemy zachęcać do wprowadzania zmian w trakcie projektu. Jedną z największych zalet filozofii Agile jest to, że dopuszcza możliwość adaptacji do sytuacji, nad którymi nie masz kontroli. Jeśli środowisko konkurencyjne ulegnie zmianie, zmienią się potrzeby Twojej firmy lub pojawi się nowa technologia, to czy kurczowe trzymanie się macierzy wymagań opracowanej kilka miesięcy wcześniej jest naprawdę pożądane? Jeśli chcesz dostarczyć swoim klientom najlepszy produkt, musisz przyjąć zmianę do wiadomości i wykorzystać ją na swoją korzyść. W Agile nie ma „zmieniania zakresu” (tutaj wstaw sztuczkę umysłową Jedi).
