
Korzystając z tego, że w zeszłym tygodniu opublikowałem poradnik o Trello, pomyślałem, że warto wyjaśnić, jak stosuję metodykę Agile w moich projektach.
Być może metodyki zwinne niewiele Ci mówią.
Albo sądzisz, że służą wyłącznie do tworzenia oprogramowania i produktów cyfrowych.
Nic bardziej mylnego: w rzeczywistości można je zastosować do dowolnego procesu, projektu czy działu.
A ten artykuł ma dwie bardzo wyraźnie oddzielone części:
- W pierwszej opowiem trochę o tym, czym są metodyki zwinne i jak to wszystko się zaczęło. Teoria stojąca za nimi i ich pojęcia.
- W drugiej części wyjaśnię Ci jak ja stosuję te elementy tej metodyki, które lubię, w zespołach marketingowych, żebyś, jeśli Cię to zainteresuje, mógł od razu zacząć stosować je w swoim. Część praktyczna i operacyjna.
Jeśli znasz już pierwszą część, możesz przejść od razu tutaj.
Zacznijmy od początku.
Część 1: Na czym polega metodyka Agile
To podejście do podejmowania decyzji w zarządzaniu projektami, które koncentruje się na rozwijaniu funkcjonalności przyrostowo i iteracyjnie, dostarczając użytkownikowi / klientowi więcej wartości w każdym cyklu.
Najpierw pojawiła się w rozwoju oprogramowania, a szybko potem zaczęto ją stosować w innych obszarach, takich jak zarządzanie projektami dowolnego rodzaju (nie tylko informatycznymi), tworzenie produktu, UX czy marketing.
Jest przeciwieństwem modeli kaskadowych -w których przed rozpoczęciem kolejnej części projektu trzeba zakończyć poprzednią- ponieważ uznaje się je za zbyt biurokratyczne, i kładzie duży nacisk na komunikację między stronami, ponad dokumentację.
Brzmi dobrze, prawda? Ale być może zastanawiasz się, skąd to wszystko się wzięło.
Zaraz zobaczysz.
Historia metodyki Agile
W połowie lat 90. pojawił się nurt sprzeciwu wobec ustrukturyzowanego zarządzania projektami, który doprowadził do spotkania w 2001 roku w Snowbird, w stanie Utah.
To tam po raz pierwszy ukuto termin „Agile Methodology”, powstała „Agile Alliance” i opublikowano „Agile Manifesto”, zawierające zasady tej metodyki.
Manifest Agile
Oryginalny dokument możesz przeczytać tutaj:
Cztery wartości Manifestu
Jak mogłeś zobaczyć pod powyższym linkiem, dokument mówi:
„Odkrywamy lepsze sposoby tworzenia oprogramowania, rozwijając je samodzielnie i pomagając innym. Dzięki tej pracy nauczyliśmy się cenić:
- Ludzi i interakcje ponad procesy i narzędzia
- Działające oprogramowanie ponad obszerną dokumentację
- Współpracę z klientem ponad negocjacje umów
- Reagowanie na zmiany ponad realizację założonego planu
Oznacza to, że choć elementy po prawej stronie mają wartość, bardziej cenimy te po lewej.”
A te cztery wartości rozwijają się w poniższych dwunastu zasadach.
Dwanaście zasad Manifestu Agile
Znajdziesz je tutaj:
http://agilemanifesto.org/principles.html
Ale je dla Ciebie przepiszę:
- “Satysfakcja klienta. To podstawa wszystkiego. Osiąga się ją poprzez dostarczanie wartościowych produktów zaspokajających potrzebę.
- Nowe wymagania są mile widziane. Zmiana w trakcie nie oznacza kroku wstecz. Każda sugestia lub rozwiązanie są mile widziane, jeśli poprawiają produkt.
- Cotygodniowe dostawy. Podział pracy na produktywne etapy jest podstawą metodyki. W miarę możliwości należy realizować jeden na tydzień.
- Postęp można mierzyć. Rozwój procesów nie jest czymś subiektywnym. Można go mierzyć za pomocą konkretnych wskaźników.
- Zrównoważony rozwój. Sposób realizacji projektów powinien sam w sobie gwarantować ich ciągłość. Nie chodzi o działanie dla samego działania.
- Bliska współpraca. Liderzy projektów powinni działać tam, gdzie faktycznie wykonywane są zadania, a nie zza biurka.
- Rozmowa twarzą w twarz. Osoba odpowiedzialna powinna skutecznie przekazywać komunikaty, najlepiej osobiście. Zaleca się regularne spotkania zarówno z klientem, jak i współpracownikami.
- Motywacja i zaufanie. Procesy odniosą sukces tylko wtedy, gdy osoby je realizujące są zmotywowane i współpracują w atmosferze zaufania i solidarności.
- Doskonałość techniczna i dobry projekt. Forma nie powinna nigdy znikać, podobnie jak jakość pracy. Wszystko tworzy całość.
- Prostota. Zadania powinny być możliwie najprostsze. Jeśli któregoś nie da się wykonać w taki sposób, należy podzielić je na iteracje, aż poziom złożoności spadnie.
- Samoorganizacja zespołów. Choć powinna istnieć osoba monitorująca zespoły, muszą one umieć organizować się samodzielnie. Nadmiar hierarchii tworzy zależności między współpracownikami.
- Dostosowanie do zmieniających się okoliczności. Projekty zazwyczaj nie kończą się tak, jak się zaczęły. Osoby je realizujące muszą umieć dostosować się do różnych okoliczności, które mogą się pojawić.”
Nie wiem, co o tym sądzisz, ale jeśli kiedykolwiek brałeś udział w tworzeniu produktów cyfrowych, trudno się z tym nie zgodzić w absolutnie każdym punkcie.
Bardzo trudno.
Do tego stopnia, że dziś, z uwagi na użyteczność w pierwotnym obszarze, metodykę tę, jak mówię, przeniesiono na zarządzanie wszelkiego rodzaju projektami, a nawet całymi sektorami.
Mówi się o „Agile Product Design”, „Agile Marketing” i „Agile Management”, gdzie zawsze próbuje się kłaść nacisk na:
- Komunikację twarzą w twarz.
- Przejrzystość.
- Satysfakcję klienta.
- Prostota.
- Rozwój przyrostowy i ciągłe doskonalenie.
Zaczynasz dostrzegać sens tej metodyki?
Przejdźmy do kluczowych elementów.
Podstawowe elementy i pojęcia metodyki Agile
Dobrze. Wszystko, co dotąd wyjaśniłem, brzmi bardzo ładnie, ale żeby zacząć, trzeba sprowadzić teorię do praktyki i wyjaśnić poszczególne elementy, które umożliwią jej zaplanowanie i realizację.
Framework
Choć wszystkie metodyki zwinne opierają się na tych samych zasadach i wartościach, każda stosuje je inaczej.
A te różne sposoby działania to różne frameworki czyli ramy odniesienia.
Jest ich kilka, każdy ma własne zasady, zalety, zalecenia i wady. Dwa najczęstsze i najbardziej znane to Kanban i Scrum.
Kanban
Powstał w Japonii po II wojnie światowej, która pogrążyła kraj w katastrofie gospodarczej i technologicznej.
W latach 50. Toyota opracowała system produkcji „just in time” (JIT) w którym każda część powstawała dokładnie we właściwym momencie, ani wcześniej, ani później, i który określono jako „wysoce skuteczny i efektywny”.
Do jego realizacji wykorzystywano karty wskazujące zapotrzebowanie na materiały w łańcuchu produkcyjnym.
Ta metodyka przejmuje więc ideę kart i utożsamia każdą z nich z zadaniem.
Tworzy się tablicę z jedną kolumną dla każdego statusu przez który musi przejść zadanie, na przykład:
- Zdefiniowane.
- W realizacji.
- Zakończone.
- Sprawdzone.

To przykład prostej tablicy, ale można ją rozbudować tak bardzo, jak wymaga tego projekt. Przykład bardziej złożonej tablicy mógłby wyglądać tak:
- Definicja.
- Analiza.
- Rozwój
- Testy.
- Wdrożenie na produkcję.
- Dokumentacja.
Tablica będzie inna dla każdej firmy lub zespołu zależnie od potrzeb i można ją stosować zarówno do projektów nowego rozwoju („uruchomić blog”, „otworzyć kanał TikTok”), jak i zadań utrzymaniowych („przegląd banerów na stronie”) czy cyklicznych („przegląd prowizji afiliacyjnych”, „cotygodniowy reporting ecommerce”).
Tablica może być fizyczna (co jest zalecane, aby była widoczna i przejrzysta dla całego zespołu) albo cyfrowa, i tu właśnie wchodzi Trello.
Scrum
Jest podobny do poprzedniego podejścia, bo jak mówiłem, zasady i filozofia, na których się opierają, są takie same.
Nazwę można przetłumaczyć jako „młyn” i pochodzi z rugby, gdy cała drużyna łączy się w zwartą formację.

Różnią się drobnymi niuansami, być może dlatego, że Scrum uchodzi za bardziej restrykcyjny i z mojego doświadczenia jest bardziej ukierunkowany na rozwój produktu cyfrowego:
- Zaleca zespoły interdyscyplinarne. Kanban dopuszcza zespoły wyspecjalizowane.
- Konkretne role: Scrum Master, Product Owner i zespół deweloperski są w Scrum obowiązkowe; w Kanban możesz je mieć lub nie
- Iteracje o określonym czasie trwania (od 1 do 4 tygodni): sprinty (kładzie się na to duży nacisk).
- Zmiany: to, co trafia do sprintu, jest niezmienne, a pożądane zmiany odkłada się do kolejnego sprintu, aby można było mierzyć proces spalania, czyli Burndown (to nie jest aż tak proste). W Kanban zmiany są łatwiejsze do wdrożenia, ponieważ funkcję o niższym priorytecie można zastąpić nową, pożądaną.
- Ceremonie o stałym czasie trwania.
- Nowa tablica w każdym sprincie kontra trwała tablica Kanban.
Z tych wszystkich powodów osobiście w Agile Marketing wolę Kanban i to właśnie jego wyjaśnię w tym artykule.
Nie jest to najczęstsze, ale widziałem i pracowałem też z modelami hybrydowymi:
- Scrum do nowych wdrożeń i Kanban do zadań cyklicznych w tym samym zespole. Tak działaliśmy w Lowi.
- Metodyka „Scrumban”, która zapożycza elementy z obu.
User stories
Być może sedno metodyki.
To prosty sposób opisania zwięzłego zadania które dostarcza wartość użytkownikowi lub klientowi.
Zazwyczaj zapisuje się je na kartach (ręcznie na karteczkach post-it albo cyfrowo) i zawierają:
- Tytuł: krótki, żeby można było się do niego odwoływać.
- Opis: Jako [rola użytkownika] chcę [funkcjonalność] aby [Cel historyjki]. Przykład: "Jako użytkownik bloga chcę widzieć powiązane artykuły na końcu artykułu, aby móc dalej czytać o interesujących mnie tematach„.
Ponadto muszą mieć następujące cechy:
- Niezależne: od siebie. Muszą dać się realizować osobno, nawet jeśli są ze sobą powiązane. Na przykład w kampanii reklamowej zadanie projektowe zostanie oddzielone od zadania copywriterskiego, choć oczywiście oba muszą być powiązane.
- Negocjowalne: zakres i szczegóły uzgadnia się między obiema stronami i w razie potrzeby renegocjuje, na przykład dzieląc zadanie na dwie części.
- Wartościowe: muszą dostarczać klientowi realną, namacalną wartość.
- Szacowalne: czyli można przeanalizować wysiłek potrzebny do ich realizacji. W czasie lub punktach deweloperskich.
- Małe: jeśli są zbyt duże i nie da się ich oszacować, trzeba je podzielić.
- Weryfikowalne: testowalne, z binarnymi kryteriami akceptacji (przechodzi albo nie przechodzi).
Po zapisaniu zadanie trafia do początkowej kolumny tablicy, a wraz ze zmianą statusu jest przesuwane między kolumnami.
Backlog
To zbiór opisanych zadań projektu, które nadal czekają na realizację.
Zespół
W zależności od metodyki posiadanie określonych ról w zespole może być konieczne albo nie.
Na przykład w Scrum zwykle mamy:
- Product Owner: osobę odpowiedzialną biznesowo za produkt.
- Scrum Master: osobę rozwiązującą problemy i ułatwiającą rozwój. Może, ale nie musi być liderem zespołu.
- Zespół deweloperski / specjaliści (UX, designerzy, SEO…): w praktyce osoby, które wykonają większość zadań.
- Tech lead: osoba technicznie odpowiedzialna za zespół. Może to być ta sama osoba, która pełni rolę Scrum Mastera.
- QA: testowanie.
W Kanban te role nie są konieczne, choć im lepiej zdefiniowana jest rola każdego członka zespołu, tym łatwiej będzie mu ocenić zadanie, a następnie je wykonać.
Sprinty
Czas trwania iteracji, cyklu lub dostawy, w której zostanie wydana jedna lub kilka nowych, priorytetowych funkcjonalności albo ulepszeń (features) produktu cyfrowego lub wykonane zostaną odpowiednie zadania tego cyklu („przygotować treści na Instagram”).
Zwykle trwają od jednego do czterech tygodni. W rozwoju produktu cyfrowego najczęściej dwa lub trzy, natomiast w marketingu mogą spokojnie trwać tydzień.
Cel Sprintu
W rozwoju produktu istnieje cel Sprintu, który skupia większość funkcjonalności planowanych do realizacji.
W innych rodzajach projektów taki cel nie zawsze jest potrzebny.
Ceremonie
Tak nazywa się spotkania zespołu charakterystyczne dla tej metodyki.
Oto najczęstsze; każda ma własny czas trwania, częstotliwość i cele:
Służą do analizowania i iteracyjnego ulepszania rozwoju i procesów
- Daily: codziennie członkowie zespołu bardzo krótko mówią, co będą robić tego dnia i czy coś blokuje wcześniejsze zadanie, aby omówić kroki potrzebne do usunięcia blokady. Powinno trwać około pięciu minut.
- Sprint plan: po zakończeniu bieżącego sprintu zespół spotyka się, żeby omówić sposób realizacji kolejnego sprintu i oszacować zadania.
- Refinement: to krok poprzedzający poprzednią ceremonię. Podczas refinement chodzi o to, by każda story była wystarczająco jasna i zrozumiała dla zespołu, a jej zakres określony tak, aby można ją było oszacować podczas Sprint plan.
- Retrospektywa: po zamknięciu sprintu analizuje się, jak poszło, jakie problemy napotkaliśmy i jakie punkty do poprawy warto uwzględnić w kolejnych sprintach.
Jeśli mówimy o marketingu, czy wszystkie te ceremonie są niezbędne?
Później podam Ci moją odpowiedź, bo tutaj kończy się teoria.
Teraz wyjaśnię, jak stosowałem to od zera w różnych zespołach i projektach.
Zobaczysz też, że podejście jest bardzo proste i nie wymaga radykalnych zmian ani nowych narzędzi, aby zacząć stosować zasady zwinności.
Część 2: Proces wdrażania metodyki Agile w Marketingu
Jeśli nigdy nie miałeś doświadczenia z metodykami zwinnymi, pierwsze, co chcę, żebyś zrobił, to przeczytać manifest i jego zasady kilka razy, bo tak naprawdę to wystarczy, aby zrozumieć i zacząć stosować niektóre pojęcia.
Chodzi o zmianę sposobu myślenia, w której powiedziałbym, że najważniejsze jest rozmawiać i dochodzić do porozumienia między stronami (szefami, własnym zespołem, zespołami zewnętrznymi…) ze świadomością, że wszyscy dążycie do wspólnego dobra.
Po drugie, być elastycznym. Rozumieć, że zmiany nadejdą i trzeba je zaakceptować. Nawet jeśli nas irytują. Nie oznacza to zawsze „ustępować”, lecz wrócić do poprzedniego punktu: rozmawiać i uzgadniać.
Po trzecie i ostatnie, mierzyć. Bo pomiar to jedyny sposób, aby wiedzieć, jak optymalna jest nasza wydajność, wydajność naszego zespołu i czy wszystkie działania, które wykonujemy, naprawdę są warte zachodu.
Dobrze, kiedy już dobrze to sobie utrwalisz, przejdźmy do systemu.
System Agile Marketing
Założenie jest takie, że Twój zespół jest w stanie wykonać ograniczoną liczbę zadań w określonym czasie.
Ten okres nazwiemy sprintem i na początek najprościej, jeśli będzie trwał tydzień.
Musisz więc zorganizować system tak, aby co tydzień (sprint) wykonywana była odpowiednia liczba zadań.
Ile to zadań? Na początku nie wiesz, bo nie masz historii. Dlatego w pierwszych sprintach możesz co najwyżej szacować z pewnym marginesem błędu, który będzie malał wraz z doświadczeniem Twoim i zespołu.
Poza tym nie macie jeszcze doświadczenia w opisywaniu zadań, co dodaje kolejny poziom trudności do szacowania.
Ale spokojnie, ten brak pewności nie potrwa długo: po kilku sprintach, pomiarach i nauczeniu się właściwego formułowania zadań będziesz mieć dane, które pozwolą znacznie lepiej oszacować każde zadanie.
Wiedząc więc, jak to będzie się rozwijać, najpierw trzeba znaleźć narzędzie, w którym utworzysz backlog i zapiszesz wszystkie zadania sprintu.
Narzędzia Agile Marketing
Masz kilka opcji, zależnie od tego, czy wolisz rozwiązania online czy offline.
Zalety każdego rodzaju?
Powiedziałbym, że online są bardziej natychmiastowe i mogą kosztować bardzo niewiele, podczas gdy offline w zasadzie składają się z tablicy i karteczek post-it, dzięki czemu cały zespół bardzo wyraźnie widzi, nad czym pracuje, a praca ta jest lepiej widoczna dla biznesu.
Moja rekomendacja?
Poza przypadkami, w których absolutnie konieczne jest bardzo wyraźne pokazanie wszystkiego, co jest robione, zacznij od narzędzia online.
Polecam dwa, zależnie od tego, jak bardzo wierzysz w ten system: Excel, jeśli chcesz spróbować, i Trello, jeśli jesteś przekonany, że to rozwiązanie dla Ciebie.
Agile Marketing z Excelem
Mówię Excel, bo jest najbardziej rozpowszechniony, ale sprawdzi się dowolny arkusz kalkulacyjny (Google Sheets, LibreOffice…).
Nie chodzi tu tyle o Kanban i tablice, ile o to, żeby od razu zacząć stosować zasady zwinne.
W tym celu utworzysz dokument, w którym będziesz dodawać wszystkie zadania do wykonania, jedno pod drugim. To będzie Twój Backlog.
Dodatkowo utworzysz szereg kolumn, które pomogą definiować każde zadanie, planować i mierzyć wydajność zespołu oraz wysiłek wymagany przez każdy typ zadania:

W tym przypadku mamy następujące kolumny:
- Priorytet: choć można by umieścić zadania o najwyższym priorytecie sprintu na górze, utrudniłoby to filtrowanie, dlatego dodajemy osobną kolumnę.
- Marka: jeśli pracujesz z kilkoma klientami lub markami, pozwoli to segmentować według każdego z nich.
- Zadania: w tym przypadku dodajemy tylko tytuł, bo zazwyczaj są to zadania, które już znamy i nie wymagają szerszego opisu.
- Komentarz: jeśli mimo wszystko potrzebujemy więcej szczegółów, dodamy je tutaj.
- Typ zadania: pozwoli nam sprawdzić, ile czasu poświęcamy na każdy rodzaj pracy, i analizować:
- Czy poświęcony czas jest tego wart.
- Czy czas wykonania maleje wraz ze wzrostem doświadczenia osoby wykonującej ten sam typ zadania.
- Osoba: czyli po prostu, kto je wykona.
- Status zadania: Nierozpoczęte, Rozpoczęte lub Zakończone.
- Data wejścia: data rozpoczęcia sprintu, dzięki której możemy filtrować, co jest realizowane w każdym sprincie.
- Start: data zmiany statusu zadania z Nierozpoczęte na Rozpoczęte.
- Godzina rozpoczęcia: godzina, o której zaczyna się zadanie.
- Godzina zakończenia: godzina, o której zadanie się kończy.
- Wysiłek w godzinach: różnica między Godziną rozpoczęcia a Godziną zakończenia.
- Tydzień: aby znać tydzień roku i móc później porównywać lub tworzyć wykresy.
W każdym sprincie dodawalibyśmy nowe zadania z ich Datą wejścia, a filtrując po tej dacie mielibyśmy już ustalony nowy sprint.
Oczywiście, jeśli zostały otwarte zadania z innych sprintów, dodajemy do filtra datę poprzedniego sprintu, aby pojawiły się zadania z obu.
Ta metoda działa, dopóki nie mamy zadań trwających dłużej niż 2 sprinty; w przeciwnym razie za bardzo by się kumulowały i trzeba byłoby znaleźć inny system, np. utworzyć w nowym sprincie nowe zadanie zastępujące to, którego nie ukończono w poprzednim.
Dobrze, taki szablon w zupełności wystarczy, aby zacząć planować i stosować trzy filary zwinności: uzgadniać, być elastycznym i mierzyć.
A gdy już trochę popracujesz -i zobaczysz, że to działa-, być może zechcesz pójść krok dalej. Wtedy nadejdzie pora na zmianę narzędzia…
Agile Marketing z Trello
Na początek masz tutaj poradnik który pomoże Ci zacząć korzystać z narzędzia.
Po przeczytaniu go i utworzeniu konta wiedz, że opublikowałem też artykuł o tym, jak używać Trello do stosowania metodyki Kanban w marketingu, gdzie wchodzę w więcej szczegółów, ale tutaj zostawiam kilka najważniejszych wskazówek:
- Na początek utwórz tylko jedną tablicę. Gdy zaczynasz, zarządzanie jest wtedy dużo prostsze.
- Na tej tablicy utwórz 3 lub 4 kolumny, nie więcej. Mogą to być:
- Backlog: backlog ze wszystkimi zadaniami, zarówno z bieżącego sprintu, jak i wszystkimi innymi dodawanymi na przyszłe sprinty.
- To do: przenieś z Backlog do tej kolumny zadania, które będą wykonywane w tym sprincie. Zadania o najwyższym priorytecie umieść na górze.
- Doing: po rozpoczęciu sprintu osoba odpowiedzialna za dane zadanie, gdy zaczyna nad nim pracę, przenosi je z kolumny To do do tej.
- Done: po zakończeniu zadania przenosi się je z kolumny Doing do tej.
- Jeśli zadanie miałoby zostać zweryfikowane przez inną osobę niż ta, która je wykonała, dodalibyśmy piątą kolumnę „Validated”.
- Po zamknięciu sprintu wszystkie zakończone zadania zostałyby zarchiwizowane, a zadania nowego sprintu zaczęlibyśmy umieszczać w To do.

Łatwe, prawda?
Teraz pozostałoby tylko dodać warstwę analizy: sprawdzić, co się stało, jeśli czegoś nie ukończono, czy problem wynikał z analizy możliwości zespołu, opisu zadania, oszacowania zadania…
A jednym ze sposobów podejścia do tego są ceremonie.
Myślę, że to Cię zainteresuje
Zarejestruj się i odbierz mój 66-stronicowy przewodnik po Najlepszych Darmowych Narzędziach Cyfrowych do:
- Marketing
- Analityka
- UX
- Zarządzanie projektami…
Dodatkowo każdego dnia w skrzynce odbiorczej otrzymasz trik lub wskazówkę (porządną) dotyczącą tego, jak ulepszyć swój biznes lub projekt cyfrowy.
Ceremonie Agile Marketing
W części teoretycznej mówiliśmy o czterech ceremoniach:
- Daily.
- Sprint plan.
- Refinement.
- Retrospektywa.
Każda jest realizowana z bardzo konkretnymi celami, ale moim zdaniem są one mocno nastawione na rozwój produktu cyfrowego i w marketingu nie wszystkie są niezbędne.
W rzeczywistości zależy to też od wielkości zespołu, bo im większy zespół, tym bardziej potrzebne stają się porządek i słuchanie innych.
Po tym wyjaśnieniu podam Ci moją opinię o każdej z nich:
Daily jest niezbędne. Jest tak dlatego, że bardzo pomaga w sprawnym działaniu zespołu i usuwa blokady, a przy tym wszyscy wiemy, na jakim etapie jesteśmy.
Z kolei sprint plan jest przydatny, choć niekonieczny, jeśli zespół jest mały (do 3-4 osób).
A refinement, jest jeszcze łatwiejszy do pominięcia, bo jeśli zespół pracuje razem od dłuższego czasu, nie potrzeba osobnej sesji do wyjaśniania rzeczy, które można rozwiązać wiadomością na Slack lub 30-sekundową rozmową między obiema stronami.
Z kolei retrospektywy są szczególnie przydatne, jeśli podczas sprintu wystąpił istotny problem. Wysłuchanie opinii każdego członka pomoże nam podejmować dobre decyzje dotyczące usprawnień.
Nie uważam jednak, że trzeba robić je po każdym sprincie (zwłaszcza jeśli sprinty są tygodniowe), ale warto przeprowadzać je okresowo oraz, jak mówię, zawsze wtedy, gdy pojawił się problem o pewnym znaczeniu.
Podsumowując, uważam, że ceremonie powinny być środkiem do osiągnięcia celu, a nie celem samym w sobie, z czym czasami się spotykałem.
Wielkość zespołu
Choć używałem opisanego dotąd systemu w zespołach liczących 10 osób, uważam, że przy takiej wielkości należałoby wprowadzić pewne korekty.
Natomiast dla mniejszych zespołów od 3 do 6 osób uważam go za idealny.
Jeśli Twój zespół jest jeszcze mniejszy, nie sądzę nawet, żeby Trello było potrzebne. Excel i Slack (lub Telegram) mogą w zupełności wystarczyć.
Zalety Agile Marketing
Najważniejsza dla mnie to możliwość posiadania widoku wszystkich zadań do realizacji w każdym sprincie, dzięki czemu jasno widzimy, które jesteśmy w stanie zrobić, a które trzeba odłożyć. Priorytetyzacja i przypisywanie zadań osobom są bardzo proste.
Pod względem organizacji to świetna sprawa, zwłaszcza dlatego, że zespół wie, co ma robić, i może się skupić na tym.
Kolejna zaleta: po wdrożeniu systemu będziemy mogli mierzyć i analizować każdy typ zadania. Jeśli porównasz wysiłek z wartością biznesową, możesz ze zdziwieniem przestać wykonywać zadania, które robisz od lat („posty na Facebooku”).
Albo odkryć, której osobie w zespole najlepiej przydzielić dane zadanie.
Kolejną zaletą jest to, że szczególnie przy Trello zamiast Excela wszystko zostaje udokumentowane, dzięki czemu mamy pod ręką prawdziwe repozytorium.
Na koniec, jeśli jest to potrzebne, jak wspominałem wcześniej, dobrze wypełniona tablica lub backlog pokazuje wartość wykonanej pracy zespołu.
Na koniec koszt tego wszystkiego jest niewielki:
- Finansowo, bo narzędzia są darmowe lub tanie.
- Czasowo, bo choć obciążenie pracą nieco rośnie, mam nadzieję, że jasno pokazałem, iż z nawiązką się to opłaca.
Wnioski
Mimo że artykuł jest dość długi, zaledwie musnąłem powierzchnię metodyki Agile.
To wprowadzenie, które ma pomóc Ci ocenić, czy to rozwiązanie dla Ciebie, czy też Twój obecny system pasuje Ci bardziej.
Niezależnie od systemów chciałbym jednak, żebyś zapamiętał trzy rzeczy, które są dla mnie jej najważniejszymi wartościami:
- Rozmawiać i uzgadniać między stronami.
- Elastyczność.
- Pomiar.
Zakładając, że wszyscy rozumiemy, iż w tym wszystkim chodzi o doprowadzenie pracy / projektu do końca.
Mam nadzieję, że udało mi się wyjaśnić wartość stosowania metodyki Agile w zespołach Marketingowych, bo dobrze wdrożona naprawdę wnosi bardzo dużo. Mówię to z własnego doświadczenia.
Więc zrób mi przysługę i daj jej szansę.
W każdym razie, choć zdecydowanie nie jestem Scrum Masterem, jeśli uważasz, że potrzebujesz pomocy w organizacji zespołu przy projektach cyfrowych, po prostu do mnie napisz.


Dodaj komentarz