Wszystkie strony Agile. Obalamy 6 nieprawdziwych opinii.

Agile jest bardzo popularny – już nie tylko w IT. Jednak mimo coraz szerszego stosowania, nadal zdarza się, że mamy problemy z pewnym zwinnymi koncepcjami i praktykami. W tym artykule obalamy kilka mitów, rzucamy nieco światła na tematy zwinne, ale nie zawsze zrozumiałe.

1. Agile to chaos – brak strategii, planowania i przewidywalności

Kiedyś usłyszałem bardzo ciekawy argument: „Agile to ciągła zmiana, więc jeśli chcemy być zwinni, planowanie nie ma sensu”. Z drugiej strony w Scrumie chociażby pracujemy w Sprintach i staramy się realizować w jakimś stopniu założone plany (na najbliższy cykl, np. 2 tygodnie). To jak to jest?

Scrum czy inne frameworki powstawały w opozycji do klasycznych, kaskadowych podejść. W starym podejściu plany miały ogromne znaczenie. Produkty rozwijało się poprzez prowadzenie sporych rozmiarów projektów. Wymagały one tak samo sporych dokumentacji i planów. Ze względu na te rozmiary właśnie, firmy, które pracowały w ten sposób, miały problem z reagowaniem na zmiany. Bo jak zawrócić 2-letni projekt w połowie drogi? Co zrobimy z tym, co już zostało wykonane? Mnóstwo z tym kłopotu!
Projekty były najpierw opisywane przez analityków, menedżerów i przekazywane dalej do zaprojektowania, a następnie wdrożenia. Przed wielkim odsłonięciem nowego produktu okazywało się, że gdzieś w pierwotnej specyfikacji popełniono błąd i jest kłopot. A może specyfikacja była w porządku, ale po blisko 2 latach od rozpoczęcia projektu klienci mają już nieco inne potrzeby, więc to, co chcemy właśnie ukończyć, nie jest już tak potrzebne. Na końcu „łańcucha pokarmowego” byli deweloperzy, którzy odpowiadali za realizację planów, ale często nie mogli ich kształtować od samego początku, bo te zostały im po prostu przekazane, co rodziło też niemało trudności.

To z takim planowaniem nie zgadza się Agile: z dużymi projektami, które mają spore specyfikacje, trwają długo bez zebrania feedbacku od klienta, a realizowane są poprzez zespoły przekazujące sobie projekt przez kolejne fazy (planowanie, projektowanie, programowanie, testowanie, wdrożenie) zamiast przez zespoły interdyscyplinarne. W Agile nie chodzi o to, aby w ogóle nie planować i żyć w chaosie. Przede wszystkim:
zmienia się skala – aby łatwiej odpowiadać na zmiany, nasze inicjatywy muszą być krótsze, a więc planowanie robimy częściej, w mniejszym zakresie,
plany tworzone są przez zespoły, które będą te plany realizowały, a nie „kogoś z zewnątrz”,
plany tworzone są w oparciu o feedback od klienta, pętlę zwrotną i są dostosowywane do zmieniającego się otoczenia – nie przywiązujemy się do nich tak mocno.

Zespoły zwinne aktywnie poszukują szans na udoskonalanie swoich produktów. Korzystają np. z danych – obserwują, jak ich produkty są używane, i na tej podstawie planują kolejne usprawnienia (wykorzystując Backlog i Sprinty). Nie trzymają się sztywno planu założonego przez menedżerów, ale też nie chodzi o to, aby czekać z założonymi rękoma na bodziec, który nas zmusi do działania. Po to m.in. w Scrumie są takie narzędzia, jak Sprint Review, po to doskonalimy regularnie Backlog i robimy Planowanie Sprintów, aby często i na małą skalę zmieniać nasz produkt.

Niejeden menedżer może zadać sobie pytanie: czy to znaczy, że nie możemy zrealizować strategii, bo zespoły będą robiły, co będą chciały? Ależ skąd! Obecnie coraz większą popularnością cieszy się narzędzie zwane OKR, czyli Objectives and Key Results. W dużym uproszczeniu: zespół otrzymuje cele od organizacji, ale decyduje o tym jakie „bitwy stoczy”, aby te cele osiągnąć – jakie dobierze narzędzia i inicjatywy. Projekty i usprawnienia produktów nie są narzucane z góry, ale powstają oddolnie, nakierowane na osiągnięcie celu. OKR to przykład jednej z wielu metod, które pozwalają menedżerom dbać o strategię, jednocześnie zostawiając sporo swobody zespołom.

2. Pasuje tylko do małych projektów

Skala czasu w Agile będzie krótka, np. w Scrumie maksymalnie miesięczna. Czy to znaczy, że tylko małe projekty można zrealizować w podejściu zwinnym? Nie. Jednak istotne będzie to, aby naszą większą inicjatywę odpowiednio podzielić i zapewnić pętlę zwrotną (feedback loop), nawet jeśli nie chcemy wydawać wszystkimi klientom „tylko w połowie gotowego produktu”. Regularnie, np. co 2 tygodnie, nasz produkt będzie się rozwijał (przyrost). Dzięki temu kod nie będzie czekał na finalny merge po wielu miesiącach, a będzie regularnie łączony i testowany. Mniej konfliktów w kodzie, mniej bugów. Jeśli nie jeszcze chcemy wydawać produktu wszystkim klientom, nasze działające oprogramowanie pozwala nam zdobywać feedback od przynajmniej wybranych z nich (tzw. pilot customers czy beta users). Możemy też, np. za pomocą tzw. feature toggle (feature flag) albo realizacji eksperymentów (np. testy A/B), pokazywać nasze zmiany w produkcie wybranemu gronu klientów. Możliwości jest sporo, ważne jednak, abyśmy regularnie upewniali się, że produkt odpowiada na realne potrzeby klientów, a kod, z którego jest zbudowany, nie czekał miesiącami na finalne połączenie.

3. Pasuje wszędzie, wystarczy wdrożyć

W „14th Annual State of Agile Report” respondenci wskazywali, że pracują zgodnie z duchem agile’owym w edukacji, służbie zdrowia, ubezpieczeniach i tak dalej. Zdarza się trafiać na opinie, że nawet w – wydawać by się mogło – skostniałych organizacjach (np. wojsko) eksperymentuje się z niezależnymi zespołami, przekazywaniem odpowiedzialności w dół łańcucha (struktury). Zachęcam do lektury chociażby „Team of Teams: New Rules of Engagement for a Complex World” Generała McChrystala, jakkolwiek nie pisze on o agile’u, jaki znany jest z IT, to wiele rzeczy jest w jego podejściu wspólnych.
To wszystko sprawia, że my też chcemy być zwinni i pełni optymizmu próbujemy „robić Scruma”. Tymczasem metody pracy trzeba dobierać bardzo świadomie, pod naszą konkretną sytuację. Konkretniej: nie ma sensu stosowanie Scruma (z jego Sprintami i pętlą zwrotną) przy produkcji czegoś, co jest używane na świecie od lat i nie zmieniło się wcale. Dlaczego? Ponieważ Scrum jest świetny do budowy produktów i realizacji inicjatyw tam, gdzie musimy się czegoś uczyć o rynku, rzeczywistość może nas zaskoczyć i musimy się dostosowywać. Dlatego jest popularny wśród startupów, które nie wiedzą, czy pomysł ich twórców jest dobry – taki pomysł to hipoteza, którą trzeba zweryfikować, a gdy okaże się trafiona, rozwijać produkt zgodnie z otrzymywanym feedbackiem.

Nie zmienia to faktu, że nawet jeśli nie użyjemy konkretnych praktyk i wydarzeń, kojarzonych z Agile, to wartości i sposób myślenia znany z Agile Manifesto są dość uniwersalne i mogą pomóc niejednej organizacji.

4. Pełno spotkań, mało realnej pracy

Wielu z nas irytują długie spotkania, które ostatecznie mogłyby być wiadomością e-mail, bo zamiast tracić czas na spotkaniu moglibyśmy pchnąć coś do przodu – mnie też. Jednak, w przeciwieństwie do wielu osób, nie winię za to Scruma czy innego frameworka, a winię raczej sposób ich używania. Scrum ma z góry założone kilka wydarzeń (np. Daily), których powinien używać zespół. Dlatego też często jest z nimi utożsamiany. I tu właśnie zaczyna się cały ten mit, że „Scrum to spotkania”. Wydarzenia są opisane, ktoś je nazwał i powiedział, że należy je praktykować. Łatwo zatem wskazać na nie, jak na problem. Jeśli nie pracujemy w Scrumie, to czy może robimy Weekly, Daily albo Retro? Agile w końcu zakłada bliską współpracę i komunikację.
Scrum nie zakłada, że będziemy spotykali się tylko dla samego spotykania. Te wydarzenia i czynności, które mamy wskazane w Scrum Guide, powinny być wystarczające dla nas, aby zrealizować założone cele. Powinny być efektywne – Daily nie musi trwać 15 minut, może trwać 3 minuty, nie może jednak tych 15 minut przekroczyć. Górna granica czasu (tzw. timebox) dla Przeglądu Sprintu, wskazana w Przewodniku po Scrumie, mówi, że dla Sprintów, trwających 1 miesiąc, Przegląd powinien trwać maksymalnie 4 godziny. Czy to znaczy, że tyle musimy czasu na to poświęcić? Nie, 30 minut, z mojego doświadczenia, jest najczęściej wystarczające.

W Scrumie jest m.in. rola Scrum Mastera, który jako facylitator wie, jak zadbać o interakcje między członkami zespołu, także na spotkaniach, aby przyniosły najlepsze efekty. Poza tym Scrum ma wskazane timeboxy, o których pisałem paragraf wcześniej. Innymi słowy: jest zaprojektowany z uwzględnieniem tego potencjalnego problemu. Zatem jeśli kolejne nasze Daily trwa 30 minut, a nie 15, a Planowanie ciągnie się w nieskończoność, to nie rezygnujmy od razu z tych spotkań – raczej zastanówmy się, co robimy źle, dlaczego one rzeczywiście tyle czasu trwają.

5. Agile się nie skaluje

Wraz z rozwojem naszego produktu i rozrostem organizacji zaczyna nam się wydawać, że Agile się nie skaluje. Mówimy „to było dobre, jak było nas 20, przy 200 osobach już nie działa”. Idąc tym tropem: wdrażamy więcej procedur, oficjalnych procesów, tworzymy role koordynatorów, menedżerów – to dość naturalne. Dobudowujemy strukturę, komplikujemy ją. Oczywiście, chcemy zachować ideę Sprintów, niezależnych zespołów, ale… nakładamy na nie coraz więcej ograniczeń, kontroli, centralizujemy wiele decyzji. Potem ogłaszamy, że „Agile nie działa przy takim rozmiarze”. Można inaczej, a problem częściej leży w kulturze organizacji, braku zaufania czy odpowiednich środowiskach i narzędziach. Rozwiązaniem nie jest usztywnianie i centralizacja, a oddanie odpowiedzialności w ręce zespołów.

Zespoły niezależne będą podejmowały szybsze decyzje, ponieważ nie muszą wciągać w proces decyzyjny tak wielu osób. Czasami mogą się mylić i podejmować je błędne, ale wówczas będzie to najczęściej kwestia wiedzy (np. dostępu do opinii klientów, danych analitycznych). Wiedzą też najczęściej, jakie mają zależności, a to, co jest im potrzebne, to nie kolejne role koordynatorskie i menedżerskie, lecz kształtowanie takiej kultury, która pozwoli im te zależności adresować samodzielnie (np. poprzez zmiany w repozytorium utrzymywanym przez inny zespół, retrospektywy z innym zespołem, odpowiednią architekturę kodu, wzmacnianie transparentności poprzez przykład). Jeśli zespół jest prawdziwie interdyscyplinarny (o takich zespołach więcej w numerze #8 naszego magazynu), to najczęściej wystarczy mu stworzyć odpowiednie warunki i postawić cele, a będziemy zaskoczeni efektami.

Oczywiście istnieją naprawdę duże produkty i korporacje, które będą potrzebowały więcej struktury i koordynacji, ale często za wcześnie chcemy przystąpić do skalowania i wprowadzać jakieś metody tego typu. Starajmy się robić to jak najpóźniej. Jeśli już możemy, używajmy frameworków lżejszych niż SAFe – LeSS chociażby. Im cięższe i bardziej skomplikowane procesy, tym mniej zwinności.

6. Dokumentacja nie ma znaczenia

Dokumentacja nierzadko już w momencie pisania przestaje być aktualna. Po napisaniu należałoby ją utrzymywać w odpowiedniej formie, a na to nie zawsze jest czas… i ochota. Do tego nawigowanie po systemie wiedzy (np. Wiki, Confluence) jest uciążliwe i skoro nie można w nim nic znaleźć, to po co w ogóle w nim cokolwiek umieszczać? Bolączek z dokumentacją jest cała masa, dlatego prawie nikt jej nie lubi. Nic dziwnego zatem, że skoro chcemy być zwinni, a w Agile Manifesto napisali, że działające oprogramowanie jest ważniejsze niż dokumentacja, to bagatelizujemy ten temat i skupiamy się na samym kodowaniu.

Konsekwencji jest sporo. Nowym pracownikom trudniej się wdrożyć bez spisanej wiedzy. Starsi stażem zapominają, jak coś działało, więc popełniają błędy. Gdy chcemy opisać, jak działa dana funkcja, musimy opisywać ją od nowa za każdym razem – zamiast wysłać link. Agile to nie brak dokumentacji, ale po prostu mądrzejsze do niej podejście.

Przede wszystkim, zgodnie z Agile Manifesto, ważniejsze od dokumentacji jest działające oprogramowanie. Jeśli nasz produkt działa poprawnie, jest łatwy w użyciu, nie wymaga instrukcji obsługi, wykonuje to, do czego został przeznaczony, to znaczna część dokumentacji już nie będzie potrzebna. Między innymi dlatego tak ważną częścią zwinnych zespołów powinny być obszary (i specjaliści) takie, jak UX (oczywiście tam, gdzie mamy do czynienia z user experience). Z punktu widzenia dewelopera przekłada się to także na kod – nie tylko mogę poklikać jak użytkownik, ale też kod jest napisany możliwie czytelnie i zrozumiale. Wówczas nie muszę tworzyć dodatkowej dokumentacji.
Czasem jednak, mimo tego, że nasz produkt działa poprawnie, a kod jest przejrzysty, i tak będziemy potrzebowali pewne sprawy zapisać. Wówczas warto pamiętać o kilku poradach. Wszelka dokumentacja dla deweloperów (np. jak technicznie zbudowany jest projekt, jak coś skonfigurować) powinna być jak najbliżej ich narzędzi pracy – można zastosować komentarze w kodzie, a jeśli to za mało, to użyjmy plików „readme” w projekcie (pierwszy plik, jaki warto przeczytać, zapoznając się z projektem). Dopiero potem skorzystajmy z narzędzi zewnętrznych (typu Confluence czy Wiki). Porównajmy to z narzędziami, których używamy do majsterkowania czy w kuchni: producent może instrukcje i wiedzę umieścić na samych narzędziach albo w oddzielnej instrukcji obsługi. Jeśli producent wybiera to pierwsze, to łatwiej nam będzie narzędziem się posługiwać.

Dokumentację, szczególnie produktową (jak coś ma działać dla użytkownika), warto też trzymać w formie FAQ dostępnego dla klientów. W takiej sytuacji nie tylko utrzymujemy wiedzę na użytek wewnętrzny, ale potencjalnie obniżamy liczbę pytań do naszego Biura Obsługi Klienta. Wizualizacja to kolejna metoda. Skoro już mamy coś opisać, to może jesteśmy w stanie zrobić to za pomocą obrazów?

Agile powstał w opozycji do klasycznego, sztywnego zarządzania projektami, w którym dokumentacja była bardzo ważna i często wyglądała jak encyklopedia. Zespoły zwinne nie powinny całkowicie rezygnować z zapisywania wiedzy – a raczej znaleźć metody lekkie i mądre.
Podsumowanie
O Scrumie kiedyś napisano, że jest „lekki, łatwy do zrozumienia, ale trudny do opanowania”. Można tak powiedzieć o większości podejść zwinnych. Osiągnięcie mistrzostwa to długa droga, często dopiero po latach zaczynamy rozumieć, jak sensownie teorię przekuwać w praktykę. Gdy zatem trafimy na zwinny problem, wróćmy do korzeni: przypomnijmy sobie, o co chodzi w tym Agile’u tak naprawdę, i wówczas może uda nam się dotrzeć do rozwiązania. Czego wszystkim czytelnikom życzę!