Co to jest Agile i na czym polega zwinne zarządzanie?

Agile to sposób organizowania pracy oparty na krótkich cyklach działania, regularnym sprawdzaniu efektów i możliwości zmiany kierunku w odpowiedzi na nowe informacje. Zamiast zakładać, że na początku projektu można przewidzieć wszystkie wymagania, problemy i potrzeby użytkowników, podejście zwinne przyjmuje, że część wiedzy pojawi się dopiero podczas realizacji.

W praktyce oznacza to budowanie produktu etapami, częste dostarczanie działających rezultatów i traktowanie informacji zwrotnej jako części procesu, a nie problemu zakłócającego wcześniej przygotowany plan. Agile jest szczególnie kojarzony z tworzeniem oprogramowania, ale jego podstawowe zasady można stosować również w projektowaniu stron internetowych, rozwijaniu sklepów, marketingu, tworzeniu usług i zarządzaniu produktami.

Co oznacza Agile?

Angielskie słowo agile oznacza zwinny, elastyczny i zdolny do szybkiego reagowania. W kontekście zarządzania projektem chodzi o zdolność zespołu lub organizacji do dostosowania się do zmieniających się warunków bez konieczności rozpoczynania całej pracy od nowa.

Agile nie oznacza jednak działania bez planu. Zwinność polega raczej na tym, że plan nie jest traktowany jak niepodważalna instrukcja na następne dwanaście miesięcy. Jest aktualizowany w miarę zdobywania nowych informacji i lepszego rozumienia problemu.

Skąd wzięło się Agile?

Podejście zwinne rozwijało się jako odpowiedź na problemy występujące przy tradycyjnym tworzeniu oprogramowania. Projekty informatyczne potrafiły trwać miesiącami lub latami, a szczegółowe wymagania były przygotowywane na samym początku. Dopiero bardzo późno użytkownik otrzymywał działający produkt i mógł sprawdzić, czy rzeczywiście odpowiada jego potrzebom.

Problem był oczywisty. W czasie długiego projektu mogły zmienić się potrzeby firmy, technologia, rynek albo oczekiwania użytkowników. Zespół mógł perfekcyjnie zrealizować dokument przygotowany rok wcześniej i jednocześnie stworzyć produkt, który w momencie premiery był już częściowo nieaktualny.

Manifest Agile

W 2001 roku grupa specjalistów zajmujących się tworzeniem oprogramowania opublikowała Manifest Agile, czyli Manifest Zwinnego Wytwarzania Oprogramowania. Dokument nie definiował konkretnego procesu ani narzędzia. Wskazywał przede wszystkim wartości i sposób myślenia o pracy nad produktem.

Cztery główne wartości Manifestu Agile mówią o większym znaczeniu:

• ludzi i interakcji niż procesów i narzędzi,
• działającego oprogramowania niż obszernej dokumentacji,
• współpracy z klientem niż negocjowania warunków kontraktu,
• reagowania na zmiany niż sztywnego realizowania planu.

Nie oznacza to, że elementy po prawej stronie są niepotrzebne. Dokument wyraźnie podkreśla ich wartość, ale wskazuje, że w sytuacji konfliktu większe znaczenie mają elementy znajdujące się po lewej.

Agile nie oznacza braku procesów

To jeden z najczęstszych mitów. Zwinny zespół nie powinien działać według zasady „robimy, co nam przyjdzie do głowy”. Wręcz przeciwnie, dobrze funkcjonujące zespoły Agile posiadają jasno określony sposób planowania pracy, ustalania priorytetów, komunikowania problemów i oceniania wyników.

Różnica polega na tym, że proces ma wspierać pracę, a nie być celem samym w sobie. Jeżeli procedura zaczyna przeszkadzać w dostarczaniu wartości, powinna zostać przeanalizowana i poprawiona.

Agile nie oznacza braku dokumentacji

Stwierdzenie, że Agile oznacza brak dokumentacji, jest błędną interpretacją Manifestu. Dokumentacja nadal może być bardzo potrzebna. Problem pojawia się wtedy, gdy firma poświęca więcej czasu na tworzenie dokumentów opisujących przyszły produkt niż na sprawdzanie rzeczywiście działającego rozwiązania.

Dobra dokumentacja powinna pomagać zespołowi, użytkownikom i osobom rozwijającym produkt w przyszłości. Nie powinna powstawać wyłącznie dlatego, że dana procedura wymaga stworzenia kolejnego dokumentu, którego później nikt nie wykorzystuje.

Agile nie oznacza braku planowania

Zwinne zarządzanie wymaga planowania, ale odbywa się ono na kilku poziomach. Można posiadać ogólną wizję produktu na wiele miesięcy, plan najbliższych etapów oraz bardzo szczegółowy zakres pracy na najbliższy tydzień lub dwa.

Im bardziej odległy termin, tym mniejszy powinien być poziom szczegółowości. Plan na następny tydzień może być bardzo konkretny. Plan na następne pół roku powinien pozostawiać miejsce na zmianę wynikającą z informacji, których dzisiaj jeszcze nie posiadamy.

Najważniejsza idea Agile: iteracja

Iteracja to krótki cykl pracy, po którym powstaje konkretny rezultat możliwy do oceny. Zamiast budować cały produkt przez rok i pokazać go użytkownikowi dopiero na końcu, można dostarczać kolejne fragmenty co kilka tygodni.

Każda iteracja pozwala odpowiedzieć na pytania: czy rozwiązanie działa, czy użytkownik je rozumie, czy nadal posiada wartość i co powinno zostać wykonane następnie. Dzięki temu błędne założenie można odkryć po dwóch tygodniach zamiast po dwunastu miesiącach.

Przyrost produktu

Przyrost, czyli increment, to działająca część produktu powstała w kolejnej iteracji. Nie musi oznaczać całkowicie nowego modułu. Może być ulepszeniem istniejącej funkcji, ale powinien tworzyć rzeczywistą wartość i zwiększać możliwości produktu.

W sklepie internetowym przyrostem może być na przykład nowy system filtrowania, usprawniony checkout albo automatyczna obsługa określonego procesu. Ważne, aby po zakończeniu prac istniał rezultat, który można uruchomić, sprawdzić i ocenić.

Feedback, czyli informacja zwrotna

Agile zakłada regularne zdobywanie informacji zwrotnej. Może pochodzić od klienta, użytkowników, zespołu sprzedaży, supportu, analityki albo samego zespołu projektowego. Informacja ta pozwala zweryfikować wcześniejsze założenia.

Feedback nie jest traktowany jak przeszkoda. Jest częścią procesu uczenia się. Jeżeli po wdrożeniu funkcji okazuje się, że użytkownicy korzystają z niej inaczej niż zakładano, zespół otrzymuje bardzo cenną informację i może odpowiednio zmienić dalszy plan.

Agile a Waterfall

Waterfall, czyli model kaskadowy, zakłada realizowanie projektu w kolejnych fazach. W uproszczeniu może to wyglądać następująco: analiza, projekt, implementacja, testy, wdrożenie. Kolejny etap rozpoczyna się po zakończeniu poprzedniego.

Takie podejście może działać bardzo dobrze tam, gdzie wymagania są stabilne i dobrze znane. Problem pojawia się w projektach, w których dużo wiedzy zdobywa się dopiero podczas tworzenia produktu. Jeżeli błędne założenie z etapu analizy zostanie odkryte dopiero podczas testów kilka miesięcy później, koszt zmiany może być bardzo duży.

Agile vs Waterfall

Najważniejsza różnica nie polega na tym, że jedno podejście jest nowoczesne, a drugie przestarzałe. Chodzi o sposób radzenia sobie z niepewnością. Waterfall lepiej sprawdza się tam, gdzie możliwe jest dokładne określenie rezultatu na początku. Agile jest szczególnie wartościowy wtedy, gdy wymagania i rozwiązanie będą ewoluować podczas pracy.

Nie każdy projekt potrzebuje zwinności. Jeżeli trzeba wdrożyć dobrze znany proces zgodnie z jednoznaczną specyfikacją, iteracyjne odkrywanie wymagań może być niepotrzebnym kosztem.

Agile a Scrum

Agile i Scrum bardzo często są błędnie traktowane jako synonimy. Agile jest szerszą filozofią i zestawem zasad. Scrum jest konkretnym frameworkiem pomagającym organizować pracę zespołu w sposób zwinny.

Można więc pracować zgodnie z zasadami Agile bez Scruma. Można również formalnie organizować spotkania Scruma i w praktyce pracować w bardzo niezwinny sposób.

Co to jest Scrum?

Scrum organizuje pracę wokół krótkich cykli określanych jako sprinty. Zespół wybiera pracę do wykonania, realizuje ją podczas sprintu, a następnie ocenia rezultat i sposób swojej pracy. Framework definiuje określone role, wydarzenia i artefakty.

W praktyce Scrum jest jednym z najbardziej rozpoznawalnych sposobów wdrażania zwinności, dlatego wiele osób pierwszy kontakt z Agile ma właśnie poprzez sprinty, backlog i daily.

Co to jest sprint?

Sprint jest ograniczonym czasowo cyklem pracy. Bardzo często trwa jeden lub dwa tygodnie, choć framework dopuszcza również inne długości w określonych granicach. W czasie sprintu zespół koncentruje się na osiągnięciu określonego celu.

Sprint nie powinien być po prostu przedziałem czasu, do którego wrzuca się przypadkową listę ticketów. Najlepiej, gdy praca tworzy logiczny krok w rozwoju produktu.

Product Backlog

Product Backlog to uporządkowana lista pracy związanej z produktem. Może zawierać nowe funkcje, poprawki, problemy techniczne, eksperymenty i inne działania potrzebne do jego rozwoju.

Backlog nie powinien być magazynem wszystkich pomysłów, które kiedykolwiek pojawiły się w firmie. Elementy powinny być regularnie oceniane i porządkowane według aktualnej wartości oraz priorytetu.

Backlog nie jest planem na zawsze

Element znajdujący się w backlogu nie musi zostać kiedykolwiek wykonany. Wraz ze zdobywaniem nowych informacji część pomysłów może stracić znaczenie, zostać zastąpiona lepszym rozwiązaniem albo całkowicie usunięta.

To jedna z kluczowych różnic pomiędzy backlogiem a sztywną specyfikacją projektu. Backlog jest żywym elementem zarządzania produktem.

Product Owner

Product Owner odpowiada przede wszystkim za maksymalizowanie wartości produktu i zarządzanie jego backlogiem. Powinien rozumieć potrzeby użytkowników i biznesu oraz pomagać zespołowi ustalać, co jest obecnie najważniejsze.

Nie powinien być wyłącznie osobą przekazującą zespołowi listę zadań od zarządu. Jego rola wymaga podejmowania decyzji dotyczących priorytetów i kierunku produktu.

Scrum Master

Scrum Master pomaga zespołowi prawidłowo wykorzystywać Scrum i usuwać przeszkody utrudniające pracę. Nie jest klasycznym kierownikiem przydzielającym zadania poszczególnym osobom.

Jego rolą jest wspieranie samoorganizacji zespołu, poprawianie procesu i pomaganie organizacji w zrozumieniu zwinnego sposobu pracy.

Daily Scrum

Daily Scrum jest krótkim, regularnym spotkaniem zespołu. Jego celem nie powinno być raportowanie kierownikowi, co każdy pracownik robił poprzedniego dnia. Spotkanie ma pomagać zespołowi zsynchronizować pracę i ustalić, czy pojawiły się przeszkody zagrażające realizacji celu sprintu.

Jeżeli daily zamienia się codziennie w godzinne spotkanie statusowe dla managementu, forma pozostała, ale sens zwinności został zgubiony.

Sprint Review

Sprint Review służy ocenie tego, co powstało, oraz rozmowie o dalszym kierunku produktu. Zespół może pokazać działający rezultat interesariuszom i zebrać informacje, które wpłyną na kolejne decyzje.

Nie powinno być to wyłącznie formalne przedstawienie slajdów opisujących wykonane zadania. Największą wartość daje kontakt z rzeczywistym działającym produktem.

Retrospektywa

Sprint Retrospective koncentruje się na sposobie pracy zespołu. Zespół analizuje, co działało dobrze, co powodowało problemy i co można zmienić w kolejnej iteracji. To mechanizm ciągłego doskonalenia samego procesu.

Retrospektywa bez późniejszej zmiany jest jednak bezwartościowa. Jeżeli co dwa tygodnie omawiany jest dokładnie ten sam problem, ale nikt nie podejmuje działania, spotkanie staje się rytuałem bez wpływu na pracę.

Agile a Kanban

Kanban jest kolejnym sposobem organizowania pracy, często stosowanym w środowiskach zwinnych. Koncentruje się na wizualizacji przepływu pracy, ograniczaniu liczby jednocześnie rozpoczętych zadań oraz poprawianiu płynności procesu.

Prosta tablica może posiadać kolumny „Do zrobienia”, „W trakcie” i „Gotowe”. Najważniejsza nie jest jednak sama tablica, ale obserwowanie przepływu oraz miejsc, w których zaczyna gromadzić się praca.

Agile a Lean

Agile i Lean posiadają wiele wspólnych idei. Oba podejścia koncentrują się na wartości, poprawianiu przepływu, ograniczaniu zbędnej pracy oraz ciągłym doskonaleniu. Lean kładzie szczególnie duży nacisk na eliminowanie marnotrawstwa i analizę całego procesu.

Agile silniej kojarzy się natomiast z iteracyjnym rozwijaniem produktów i reagowaniem na zmieniające się wymagania. W praktyce nowoczesne zespoły bardzo często korzystają z elementów obu podejść.

Agile a Lean Management

Lean Management można stosować w całej organizacji, analizując między innymi przepływ informacji, oczekiwanie, przeciążenie i zbędne działania. Agile częściej koncentruje się na sposobie rozwijania produktu w warunkach niepewności.

Nie są to konkurencyjne filozofie. Zespół może rozwijać produkt iteracyjnie zgodnie z Agile i jednocześnie analizować swój proces według zasad Lean.

Agile a MVP

MVP, czyli Minimum Viable Product, bardzo dobrze wpisuje się w zwinny sposób myślenia. Zamiast budować kompletny produkt przez długi czas na podstawie niesprawdzonych założeń, tworzy się minimalną wersję pozwalającą zweryfikować najważniejsze hipotezy.

MVP nie oznacza produktu złej jakości. Powinien być wystarczająco kompletny, aby można było sprawdzić jego kluczową wartość. Chodzi o ograniczenie inwestowania czasu w elementy, których znaczenie nie zostało jeszcze potwierdzone.

Build, Measure, Learn

Bliska Agile jest również idea cyklu Build, Measure, Learn znana z Lean Startup. Najpierw powstaje rozwiązanie, następnie mierzy się jego działanie i na podstawie wyników wyciąga wnioski. Kolejna wersja produktu powstaje już z większą wiedzą.

Kluczowa jest szybkość całego cyklu. Im szybciej firma potrafi zweryfikować założenie, tym mniej zasobów ryzykuje przy błędnym kierunku.

User Story

User Story to popularny sposób zapisywania potrzeby użytkownika. Zamiast opisywać wyłącznie funkcję techniczną, próbuje pokazać ją z perspektywy osoby, która ma z niej korzystać.

Klasyczna konstrukcja może wyglądać następująco: jako określony użytkownik chcę wykonać określone działanie, aby osiągnąć określoną korzyść. Najważniejsza nie jest jednak sama formułka, lecz zrozumienie celu funkcji.

Przykład User Story

Zamiast zadania „Dodać eksport CSV” można zapisać potrzebę: „Jako administrator chcę wyeksportować listę zamówień do CSV, żebym mógł przekazać dane do systemu księgowego”. Druga wersja mówi znacznie więcej o rzeczywistym problemie.

Może się nawet okazać, że eksport CSV nie jest najlepszym rozwiązaniem. Jeśli celem jest przekazanie danych do księgowości, być może lepsza będzie bezpośrednia integracja.

Acceptance Criteria

Kryteria akceptacji określają warunki, które rozwiązanie musi spełnić, aby można było uznać daną funkcję za poprawnie wykonaną. Pomagają ograniczyć różnice w interpretacji wymagań.

Dla eksportu zamówień można określić między innymi zakres pól, obsługiwany format, sposób filtrowania i zachowanie przy dużej liczbie rekordów. Dzięki temu zespół wie, czego dokładnie oczekuje produkt.

Definition of Done

Definition of Done określa wspólne kryteria pozwalające uznać pracę za rzeczywiście ukończoną. Sam fakt, że programista napisał kod, nie musi oznaczać zakończenia zadania. Może być jeszcze potrzebny test, review, dokumentacja albo wdrożenie.

Bez wspólnej definicji „gotowe” jedna osoba może rozumieć jako „napisałem kod”, druga jako „działa na środowisku testowym”, a trzecia jako „użytkownik już może z tego korzystać”.

Estymacja w Agile

Zespoły zwinne często próbują szacować wielkość lub złożoność pracy. Nie zawsze robią to bezpośrednio w godzinach. Popularnym rozwiązaniem są Story Points, które mogą uwzględniać złożoność, ryzyko i niepewność.

Estymacja nie powinna jednak tworzyć fałszywego poczucia precyzji. Stwierdzenie, że nieznany projekt potrwa dokładnie 427 godzin, nie staje się bardziej wiarygodne tylko dlatego, że liczba jest szczegółowa.

Story Points

Story Points służą do relatywnego porównywania pracy. Zadanie ocenione na osiem punktów jest postrzegane jako większe lub bardziej złożone niż zadanie ocenione na trzy punkty.

Punkty nie powinny być automatycznie przeliczane na godziny i wykorzystywane do porównywania wydajności pracowników. W takim przypadku bardzo szybko tracą swoją pierwotną funkcję.

Velocity

Velocity opisuje ilość pracy realizowaną przez zespół w kolejnych sprintach, często mierzoną w Story Points. Może pomagać w planowaniu, jeśli zespół posiada stabilny sposób estymowania.

Velocity nie powinno jednak stać się KPI służącym do oceniania produktywności. Jeżeli management wymaga zwiększenia liczby punktów o 20%, zespół może po prostu zmienić sposób przyznawania punktów. Produkt nie powstanie od tego szybciej.

Agile a deadline

Zwinność nie oznacza, że projekty nie posiadają terminów. Wiele produktów musi zostać uruchomionych przed konkretnym wydarzeniem, sezonem sprzedażowym albo zmianą prawną.

Agile pomaga wtedy zarządzać zakresem i priorytetami. Jeżeli termin jest stały, można zdecydować, które elementy są absolutnie niezbędne, a które mogą zostać dostarczone później.

Zakres, czas i budżet

Projekt posiada kilka ograniczeń, które wpływają na siebie nawzajem. Jeżeli czas i budżet są sztywne, zakres musi posiadać pewną elastyczność. Próba utrzymania jednocześnie niezmiennego terminu, budżetu i pełnej listy funkcji mimo nowych problemów bardzo często kończy się spadkiem jakości.

Priorytetyzacja

Agile wymaga ciągłego podejmowania decyzji dotyczących tego, co zrobić najpierw. Backlog posiadający 500 elementów nie pomaga, jeśli wszystkie są oznaczone jako „wysoki priorytet”.

Priorytet powinien wynikać między innymi z wartości biznesowej, wpływu na użytkownika, ryzyka, kosztu i zależności z innymi elementami.

MoSCoW

Jedną z metod priorytetyzacji jest MoSCoW. Elementy dzieli się na:

• Must have,
• Should have,
• Could have,
• Won't have now.

Metoda pomaga rozróżnić funkcje naprawdę krytyczne od tych, które po prostu byłyby przydatne. Problem pojawia się wtedy, gdy prawie wszystko trafia do kategorii Must have.

Agile w tworzeniu stron internetowych

Zwinne podejście bardzo dobrze sprawdza się podczas tworzenia bardziej rozbudowanych stron. Zamiast projektować w szczegółach cały serwis przed rozpoczęciem wdrożenia, można najpierw przygotować architekturę i kluczowe typy podstron, uruchomić działającą wersję oraz iteracyjnie rozwijać kolejne elementy.

Nie oznacza to, że należy publikować przypadkowo niedokończoną stronę. Chodzi o podział projektu na sensowne części pozwalające wcześniej zobaczyć działający rezultat.

Agile a redesign strony

Przy redesignie można rozpocząć od najważniejszych problemów zamiast przebudowywać wszystko jednocześnie. Jeżeli dane pokazują, że największym problemem jest proces kontaktu albo mobile, właśnie ten obszar może zostać potraktowany priorytetowo.

Dzięki temu projekt nie jest oparty wyłącznie na założeniu „zróbmy wszystko od nowa”. Zmiany mogą być weryfikowane etapami.

Agile w e-commerce

Sklep internetowy jest produktem, który praktycznie nigdy nie jest ostatecznie skończony. Zmieniają się produkty, promocje, sposoby płatności, integracje, oczekiwania klientów i technologie. Zwinne podejście pozwala rozwijać go stopniowo.

Można na przykład najpierw poprawić filtry, następnie checkout, później wyszukiwarkę, a kolejne decyzje podejmować na podstawie wyników. Przy tworzeniu i rozwijaniu sklepów WooCommerce takie iteracyjne podejście jest szczególnie praktyczne, ponieważ nie wymaga zatrzymywania rozwoju sklepu do czasu przygotowania jednej wielkiej przebudowy.

Agile w dedykowanych systemach

W systemach biznesowych bardzo trudno przewidzieć wszystkie wymagania przed rozpoczęciem pracy. Użytkownik może opisać swój proces, ale dopiero po zobaczeniu pierwszego działającego modułu zauważyć, które elementy są naprawdę wygodne, a które wymagają zmiany.

Dlatego przy dedykowanych systemach operacyjnych iteracyjne rozwijanie rozwiązania może być znacznie bezpieczniejsze niż próba szczegółowego zaprojektowania całej aplikacji wyłącznie na podstawie początkowej dokumentacji.

Agile w marketingu

Zwinne podejście można wykorzystywać również w marketingu. Zamiast tworzyć roczny plan zakładający dokładne działania na każdy tydzień, można posiadać kierunek strategiczny i regularnie dostosowywać wykonanie na podstawie wyników kampanii.

Przykładem może być testowanie różnych komunikatów, formatów treści i landing pages. Wynik jednej iteracji dostarcza informacji potrzebnych do zaplanowania kolejnej.

Agile Marketing

Agile Marketing przenosi część zasad zwinnych do pracy zespołów marketingowych. Duży nacisk kładzie na krótkie eksperymenty, analizę wyników, współpracę i zmianę priorytetów w zależności od tego, co rzeczywiście działa.

Nie oznacza to rezygnacji ze strategii marki. Strategia może być stabilna, a sposób jej realizacji znacznie bardziej elastyczny.

Agile w małej firmie

Mała firma nie musi wdrażać formalnego Scruma, posiadać Scrum Mastera i organizować pięciu rodzajów spotkań, aby korzystać ze zwinnego sposobu myślenia. Czasami wystarczy podzielić duży projekt na mniejsze etapy, ustalić priorytety i regularnie oceniać rezultat.

Formalny framework powinien odpowiadać skali problemu. Zespół dwóch osób nie potrzebuje procesu zaprojektowanego dla kilkudziesięciu specjalistów pracujących nad ogromnym produktem.

Agile w jednoosobowej działalności

Elementy Agile można wykorzystać nawet pracując samodzielnie. Zamiast rozpoczynać dziesięć projektów naraz, można utrzymywać backlog, ograniczać pracę w toku, ustalać krótkie cele i regularnie oceniać, które działania rzeczywiście przynoszą rezultat.

Najważniejsza pozostaje zdolność do zmiany priorytetu, jeśli nowe informacje pokazują, że dotychczasowy plan nie ma już sensu.

Agile a klient

Zwinny projekt wymaga zaangażowania klienta lub osoby reprezentującej potrzeby biznesowe. Jeżeli zespół przez kilka miesięcy nie może uzyskać żadnej decyzji ani feedbacku, trudno mówić o prawdziwie iteracyjnym rozwoju produktu.

Klient nie musi uczestniczyć w każdej technicznej decyzji. Powinien jednak regularnie oceniać rezultat i pomagać ustalać priorytety.

Zmiana wymagań w Agile

Zmiana nie jest automatycznie błędem. Może wynikać z nowej wiedzy. Jeżeli użytkownicy pokazali, że pierwotnie planowana funkcja nie rozwiązuje problemu, utrzymywanie jej wyłącznie dlatego, że znajduje się w umowie od sześciu miesięcy, może prowadzić do marnowania zasobów.

Z drugiej strony Agile nie oznacza, że wymagania można zmieniać bez żadnej kontroli co kilka godzin. Potrzebny jest proces ustalania priorytetów i zarządzania wpływem zmian na pozostałą pracę.

Scope creep

Scope creep oznacza niekontrolowane rozszerzanie zakresu projektu. Pojawiają się kolejne drobne funkcje, dodatkowe wymagania i pomysły, ale czas oraz budżet pozostają bez zmian.

Agile nie powinien usprawiedliwiać scope creep. Nowa funkcja może trafić do backlogu, ale nadal trzeba zdecydować, czy jest ważniejsza od rzeczy znajdujących się już na liście.

Agile a jakość

Szybkie iteracje nie oznaczają zgody na niską jakość. Jeżeli każda kolejna wersja produktu dokłada błędy i dług techniczny, zespół z czasem zaczyna pracować coraz wolniej.

Jakość powinna być częścią Definition of Done, a nie zadaniem odkładanym na moment, kiedy „będzie więcej czasu”.

Technical Debt

Dług techniczny powstaje, gdy zespół wybiera rozwiązanie szybsze w krótkim terminie, ale wymagające dodatkowej pracy w przyszłości. Nie każdy dług techniczny jest automatycznie błędem. Czasami może być świadomą decyzją biznesową.

Problem pojawia się wtedy, gdy dług narasta bez kontroli. Po pewnym czasie każda nowa funkcja wymaga coraz większej liczby obejść i poprawek.

Refactoring

Refactoring polega na poprawianiu wewnętrznej struktury kodu bez zmiany jego zewnętrznego działania. Regularny refactoring pomaga ograniczać narastanie długu technicznego i utrzymywać możliwość dalszego szybkiego rozwoju produktu.

Jeżeli zespół zawsze wybiera wyłącznie funkcje widoczne dla klienta i nigdy nie inwestuje w jakość techniczną, prędzej czy później szybkość rozwoju zacznie spadać.

Agile i testowanie

Testowanie powinno być częścią każdej iteracji, a nie osobnym etapem wykonywanym kilka miesięcy po zakończeniu developmentu. Im szybciej problem zostanie znaleziony, tym zazwyczaj taniej można go naprawić.

Automatyczne testy mogą dodatkowo pozwolić szybko sprawdzać, czy kolejna zmiana nie zepsuła wcześniej działających funkcji.

Continuous Integration

Continuous Integration, czyli ciągła integracja, polega na częstym łączeniu zmian w kodzie i automatycznym sprawdzaniu ich poprawności. Zamiast przez kilka tygodni tworzyć oddzielne fragmenty, które dopiero na końcu próbuje się połączyć, zespół integruje pracę regularnie.

Zmniejsza to ryzyko dużych konfliktów oraz pozwala wcześniej wykrywać problemy.

Continuous Delivery

Continuous Delivery rozwija tę ideę i zakłada utrzymywanie produktu w stanie pozwalającym na częste oraz bezpieczne wdrożenia. Nie oznacza to koniecznie publikowania każdej zmiany natychmiast po napisaniu kodu.

Najważniejsze jest ograniczenie wielkiego, stresującego „dnia wdrożenia”, podczas którego jednocześnie publikowanych jest kilkaset zmian powstałych przez kilka miesięcy.

Agile a DevOps

DevOps łączy rozwój oprogramowania z jego utrzymaniem i eksploatacją. Bardzo dobrze współgra z Agile, ponieważ częste iteracje wymagają sprawnego procesu budowania, testowania, wdrażania i monitorowania produktu.

Jeżeli stworzenie funkcji trwa dwa dni, ale jej publikacja wymaga później trzech tygodni procedur, organizacja nadal posiada bardzo wolny przepływ wartości.

Agile a UX

Projektowanie UX również może być prowadzone iteracyjnie. Zamiast przygotowywać cały interfejs aplikacji przed rozpoczęciem developmentu, można projektować najważniejsze procesy, tworzyć prototypy, testować je i rozwijać w kolejnych cyklach.

Trzeba jednak uważać, aby UX nie znalazł się zawsze dokładnie jeden dzień przed developmentem. Projektant potrzebuje czasu na analizę, badania i sprawdzenie rozwiązań. Agile nie powinien oznaczać projektowania wszystkiego na ostatnią chwilę.

Dual Track Agile

Dual Track Agile rozdziela dwa powiązane strumienie pracy. Discovery służy odkrywaniu problemów i sprawdzaniu rozwiązań, natomiast Delivery koncentruje się na budowaniu i dostarczaniu już zweryfikowanych elementów.

Dzięki temu zespół nie musi rozpoczynać developmentu każdej funkcji natychmiast po pojawieniu się pomysłu. Najpierw można sprawdzić, czy problem naprawdę istnieje i czy proponowany sposób jego rozwiązania ma sens.

Discovery

Product Discovery obejmuje działania pomagające zrozumieć potrzeby użytkowników oraz znaleźć rozwiązanie warte zbudowania. Mogą to być wywiady, prototypy, analiza danych, eksperymenty i testy użyteczności.

Discovery zmniejsza ryzyko stworzenia funkcji technicznie poprawnej, której nikt nie potrzebuje.

Delivery

Delivery oznacza dostarczanie produktu. Obejmuje projektowanie szczegółów, development, testowanie i wdrożenie. Dobry proces łączy Discovery i Delivery tak, aby zespół cały czas uczył się i jednocześnie dostarczał realną wartość.

Agile a roadmapa

Roadmapa produktu pokazuje kierunek jego rozwoju. W podejściu zwinnym nie powinna być traktowana jak dokładny harmonogram wszystkich funkcji na następne dwa lata.

Może przedstawiać cele, problemy do rozwiązania i główne obszary rozwoju. Szczegóły najbliższych działań są bardziej konkretne, natomiast dalsza przyszłość pozostaje elastyczna.

Outcome zamiast output

Agile bardzo dobrze współgra z podejściem koncentrującym się na rezultacie biznesowym zamiast samej liczby wykonanych funkcji. Output oznacza to, co zespół wyprodukował. Outcome oznacza zmianę, którą dzięki temu osiągnięto.

„Dodaliśmy pięć nowych funkcji” jest outputem. „Skróciliśmy czas przygotowania oferty z dwudziestu do pięciu minut” jest outcome. Druga informacja znacznie lepiej pokazuje wartość produktu.

Feature Factory

Feature Factory to krytyczne określenie organizacji, która koncentruje się głównie na produkowaniu kolejnych funkcji. Sukces mierzy się liczbą ukończonych ticketów, a nie tym, czy użytkownikom lub biznesowi rzeczywiście jest lepiej.

Taki zespół może posiadać sprinty, daily, backlog i wszystkie rytuały Scruma, a jednocześnie nie być naprawdę zwinny.

Agile Theater

Agile Theater oznacza sytuację, w której organizacja odtwarza ceremonie i słownictwo Agile, ale nie zmienia sposobu podejmowania decyzji. Istnieją sprinty i retrospektywy, ale plan na rok pozostaje całkowicie sztywny, zmiana jest źle widziana, a feedback użytkowników nie wpływa na backlog.

Forma została wdrożona, ale podstawowa idea zwinności nie.

Najczęstszy błąd: Agile oznacza szybciej

Zwinność może przyspieszyć dostarczanie wartości, ale Agile nie jest metodą zmuszania zespołu do wykonywania dwa razy większej liczby zadań. Celem jest między innymi ograniczenie pracy nad niewłaściwymi rzeczami i wcześniejsze wykrywanie błędnych założeń.

Jeżeli organizacja wdraża Scrum tylko po to, aby „programiści szybciej kodowali”, prawdopodobnie nie rozwiązuje najważniejszego problemu.

Najczęstszy błąd: brak jasnego celu

Zespół może bardzo sprawnie wykonywać sprint za sprintem i nadal nie wiedzieć, dokąd zmierza produkt. Agile nie zastępuje strategii. Potrzebna jest wizja i jasne cele pozwalające podejmować decyzje dotyczące backlogu.

Najczęstszy błąd: codzienne zmiany priorytetów

Reagowanie na zmianę nie oznacza ciągłego chaosu. Jeżeli każdego dnia wszystkie zadania są przestawiane według najnowszej wiadomości od klienta albo managera, zespół nie posiada możliwości skoncentrowania się na pracy.

Zwinność wymaga mechanizmu zarządzania zmianą, a nie nieustannego przerywania rozpoczętych działań.

Najczęstszy błąd: wszystko jest pilne

Backlog, w którym każdy element ma najwyższy priorytet, nie posiada priorytetów. Jedną z najtrudniejszych części zarządzania produktem jest świadoma decyzja, czego obecnie nie robić.

Najczęstszy błąd: za dużo pracy w toku

Zespół rozpoczyna wiele funkcji jednocześnie, ale niewiele z nich kończy. Każde przełączanie kontekstu generuje dodatkowy koszt, a realna wartość trafia do użytkownika dopiero po ukończeniu pracy.

Ograniczenie WIP znane z Kanban może znacznie poprawić przepływ również w zespołach pracujących iteracyjnie.

Najczęstszy błąd: sprint jako mini Waterfall

Można podzielić pracę na dwutygodniowe sprinty, ale nadal realizować wewnątrz nich schemat: kilka dni analizy, kilka dni designu, development na końcu i testowanie w ostatni wieczór. Formalnie istnieją sprinty, ale współpraca i ciągły przepływ pozostają ograniczone.

Najczęstszy błąd: brak kontaktu z użytkownikiem

Zespół może przez wiele sprintów realizować backlog przygotowany przez managerów bez żadnego kontaktu z osobami korzystającymi z produktu. Taki proces posiada rytuały Agile, ale traci jeden z najważniejszych mechanizmów uczenia się.

Najczęstszy błąd: retrospektywa bez zmian

Jeżeli podczas każdej retrospektywy pojawia się problem „za dużo spotkań”, ale po roku liczba spotkań nadal rośnie, zespół nie wykorzystuje retrospektywy zgodnie z jej celem. Każda analiza powinna prowadzić przynajmniej do małego eksperymentu poprawiającego proces.

Najczęstszy błąd: Scrum dla każdego problemu

Scrum jest narzędziem, a nie obowiązkowym systemem organizacji każdej pracy. Zespół obsługujący nieprzewidywalne zgłoszenia serwisowe może znacznie lepiej działać w Kanban niż próbować sztucznie wciskać awarie do dwutygodniowych sprintów.

Framework powinien być dopasowany do charakteru pracy.

Najczęstszy błąd: zbyt dużo ceremonii

Spotkania mają wspierać komunikację i podejmowanie decyzji. Jeżeli zespół większość dnia spędza na ceremoniach dotyczących pracy zamiast na samej pracy, proces wymaga optymalizacji.

Agile nie jest konkursem na liczbę spotkań.

Agile a praca zdalna

Zwinne zespoły mogą bardzo dobrze pracować zdalnie, ale potrzebują dobrej komunikacji i przejrzystości pracy. Tablica zadań, jasne decyzje i dostępna dokumentacja stają się jeszcze ważniejsze, gdy zespół nie siedzi w jednym pomieszczeniu.

Nie oznacza to jednak konieczności zastępowania każdego kontaktu spotkaniem wideo. Wiele informacji można skuteczniej przekazać asynchronicznie.

Komunikacja synchroniczna i asynchroniczna

Spotkanie jest dobre wtedy, gdy potrzebna jest rozmowa, szybka decyzja albo wspólne rozwiązanie problemu. Status, który każdy może przeczytać w systemie, nie zawsze wymaga trzydziestominutowego calla.

Dobrze działający zespół świadomie dobiera sposób komunikacji do rodzaju informacji.

Samoorganizujący się zespół

Agile zakłada dużą odpowiedzialność zespołu za sposób realizacji celu. Management może określać priorytet biznesowy, ale osoby posiadające wiedzę techniczną powinny mieć wpływ na sposób wykonania rozwiązania.

Samoorganizacja nie oznacza braku odpowiedzialności. Oznacza przesunięcie części decyzji bliżej osób posiadających najlepszą wiedzę o problemie.

Cross-functional team

Zespół cross-functional posiada kompetencje potrzebne do dostarczenia wartości bez ciągłego oczekiwania na inne działy. Może łączyć programowanie, UX, testowanie, analizę i inne specjalizacje potrzebne w konkretnym produkcie.

Jeżeli każde zadanie przez tydzień czeka na wolny dział zewnętrzny wobec zespołu, iteracyjna praca zaczyna tracić płynność.

Agile a leadership

Zwinna organizacja nadal potrzebuje liderów. Ich rola zmienia się jednak z wydawania szczegółowych instrukcji na tworzenie warunków pozwalających zespołowi podejmować dobre decyzje.

Lider powinien pomagać usuwać bariery, wyjaśniać cele i zapewniać dostęp do informacji. Mikrozarządzanie każdą czynnością jest trudne do pogodzenia z samoorganizacją.

Agile a kultura organizacyjna

Największą barierą wdrażania Agile często nie jest brak znajomości Scruma, ale kultura firmy. Jeżeli pracownicy boją się powiedzieć, że plan jest błędny, nie ma przestrzeni na prawdziwą adaptację.

Zwinność wymaga możliwości otwartego zgłaszania problemów, testowania nowych rozwiązań i przyznawania, że wcześniejsze założenie okazało się niepoprawne.

Fail fast

Hasło fail fast jest czasami błędnie rozumiane jako zachęta do produkowania błędów. Chodzi raczej o szybkie wykrywanie nietrafionych założeń przy możliwie małym koszcie.

Jeżeli pomysł jest zły, lepiej odkryć to po prostym prototypie niż po roku developmentu.

Eksperyment zamiast wielkiego wdrożenia

Nie każda decyzja wymaga natychmiastowej przebudowy całego produktu. Można rozpocząć od małego eksperymentu, ograniczonej grupy użytkowników lub testu A/B. Wynik pozwala zdecydować, czy warto inwestować dalej.

Agile a dane

Zwinne podejście jest znacznie silniejsze, gdy decyzje można opierać na danych. Po wdrożeniu funkcji warto wiedzieć, czy użytkownicy z niej korzystają i czy poprawił się wskaźnik, który miał zostać zmieniony.

Sam fakt dostarczenia funkcji nie dowodzi jej wartości.

Agile Metrics

Zespół może monitorować między innymi czas realizacji, przepustowość, liczbę błędów i stabilność procesu. Wskaźniki powinny jednak pomagać poprawiać pracę, a nie tworzyć presję na sztuczne zwiększanie liczb.

Każda metryka wykorzystywana jako cel może zacząć wpływać na zachowanie ludzi w sposób, który niszczy jej pierwotne znaczenie.

Lead Time

Lead Time mierzy czas od pojawienia się potrzeby do dostarczenia rezultatu. Jeżeli funkcja czeka trzy miesiące w kolejce, a development zajmuje dwa dni, samo przyspieszenie programowania nie rozwiązuje głównego problemu.

Cycle Time

Cycle Time opisuje czas, przez który element rzeczywiście znajduje się w procesie realizacji. Pozwala analizować, jak szybko zespół potrafi zakończyć rozpoczętą pracę.

Długie czasy mogą wskazywać na zbyt duże zadania, zależności, oczekiwanie na decyzje albo za dużą liczbę równolegle rozpoczętych tematów.

Agile a automatyzacja

Automatyzacja może bardzo dobrze wspierać zwinny proces. Automatyczne testy, deployment, powiadomienia i integracje skracają czas pomiędzy zmianą a możliwością jej zweryfikowania.

Nie warto jednak automatyzować procesu tylko dlatego, że jest częścią nowoczesnego workflow. Podobnie jak w Lean, najpierw trzeba sprawdzić, czy dana czynność rzeczywiście jest potrzebna.

Czy Agile zawsze działa?

Nie. Agile nie jest uniwersalnym lekarstwem na każdy problem organizacyjny. Jeżeli zakres jest całkowicie stabilny, wymagania są jednoznaczne, a rezultat dokładnie znany, bardziej klasyczne zarządzanie może być prostsze i tańsze.

Agile również nie naprawi automatycznie braku kompetencji, chaosu decyzyjnego, konfliktów między działami ani złej strategii produktu.

Kiedy Agile sprawdza się najlepiej?

Zwinne podejście ma szczególnie dużą wartość, gdy istnieje niepewność dotycząca rozwiązania lub wymagań. Sprawdza się w produktach cyfrowych, startupach, rozwijaniu sklepów, aplikacji i usług, w których możliwe jest regularne dostarczanie kolejnych wersji.

Jest również przydatne tam, gdzie rynek zmienia się szybko i firma musi reagować na informacje pojawiające się już podczas realizacji projektu.

Kiedy Agile może być niepotrzebne?

Jeżeli projekt polega na wykonaniu jednoznacznej, powtarzalnej operacji według dokładnie określonych wymagań, rozbudowany framework Agile może stworzyć więcej pracy administracyjnej niż wartości.

Nie warto wdrażać sprintów, daily i retrospektyw tylko dlatego, że termin Agile dobrze wygląda w prezentacji.

Jak zacząć pracować zwinnie?

Nie trzeba rozpoczynać od wielkiej transformacji całej organizacji. Można wybrać jeden projekt i wprowadzić kilka podstawowych zasad: podzielić pracę na mniejsze rezultaty, ustalić jasny priorytet, ograniczyć liczbę tematów wykonywanych jednocześnie i regularnie sprawdzać rezultat z osobą reprezentującą użytkownika lub biznes.

Po każdej iteracji warto odpowiedzieć na pytania: czego się dowiedzieliśmy, co zmieniło się w naszych założeniach i jaki kolejny krok daje obecnie największą wartość.

Nie zaczynaj od narzędzia

Zakup Jira, stworzenie tablicy Kanban albo zatrudnienie Scrum Mastera nie powoduje automatycznie, że organizacja staje się Agile. Najpierw trzeba ustalić, jaki problem ma rozwiązać zmiana sposobu pracy.

Narzędzie powinno wspierać proces. Nie powinno go definiować.

Nie kopiuj procesu innej firmy

Proces działający w globalnej firmie technologicznej może być absurdalnie rozbudowany dla małej organizacji. Z drugiej strony proces wystarczający dla trzech osób może nie działać przy stuosobowym produkcie.

Zwinność oznacza również dostosowywanie samego sposobu pracy do własnego kontekstu.

Agile jako sposób myślenia

Najważniejsza część Agile znajduje się głębiej niż sprinty, tablice i nazwy ról. Chodzi o zaakceptowanie, że przy złożonych projektach nie da się wszystkiego przewidzieć z góry. Zamiast ukrywać tę niepewność pod bardzo szczegółowym harmonogramem, można budować system pozwalający szybko zdobywać wiedzę i reagować na nią.

W takim podejściu plan jest hipotezą, produkt źródłem informacji, a zmiana nie musi oznaczać porażki projektu. Może być dowodem, że organizacja nauczyła się czegoś nowego.

Co warto zapamiętać o Agile?

Agile to zwinny sposób rozwijania produktów i organizowania pracy oparty na krótkich iteracjach, regularnym feedbacku i możliwości reagowania na nowe informacje. Nie jest pojedynczą metodą ani synonimem Scruma. Scrum, Kanban i inne podejścia są sposobami realizowania części zasad związanych ze zwinnością.

Agile nie oznacza braku planowania, dokumentacji ani odpowiedzialności. Oznacza natomiast, że żadnego z tych elementów nie należy traktować jako ważniejszego od rzeczywistej wartości dostarczanej użytkownikowi. Plan może się zmienić, jeśli pojawią się informacje pokazujące lepszy kierunek.

Największą zaletą zwinnego podejścia jest możliwość wcześniejszego wykrywania błędnych założeń. Zamiast przez wiele miesięcy budować produkt i dopiero na końcu sprawdzić jego sens, można dostarczać kolejne przyrosty, mierzyć rezultaty i na tej podstawie planować następne działania.

Agile działa jednak tylko wtedy, gdy organizacja rzeczywiście dopuszcza zmianę, potrafi ustalać priorytety i korzysta z informacji zwrotnej. Same sprinty, daily i backlog nie tworzą zwinności. Mogą być jedynie rytuałami, jeśli decyzje nadal są podejmowane według sztywnego planu niezależnie od tego, czego firma nauczyła się podczas realizacji projektu.