Dlaczego Agile bywa niezrozumiany?

Podstawy Agile

Na początku sięgnijmy do tego, co jest podstawą każdego frameworku zwinnego wytwarzania oprogramowania, czyli do „Manifestu Agile”. Przedkłada on:

• ludzi i interakcje ponad procesy i narzędzia,
• działające oprogramowanie ponad obszerną dokumentację,
• współpracę z klientem ponad formalne ustalenia,
• reagowanie na zmiany ponad podążanie za planem.

Wszystko to, czyli nacisk na komunikację – także z klientem – skupienie się na dostarczeniu wysokiej jakości oprogramowania, a nie na tworzeniu obszernej dokumentacji projektowej, oraz elastyczność w realizacji projektu wpływa na sposób planowania. W odróżnieniu od modelu kaskadowego, w którym projekt planuje się długofalowo, pracę dzielimy na Sprinty. Dlaczego mimo coraz większej popularności Agile bywa niezrozumiany? O tym piszę poniżej.

Zwinna organizacja

Daily, Review, Retro… Wszyscy, którzy pracują we frameworku Scrum, słyszą te określenia wielokrotnie, nieraz codziennie, i nie mają one dla nich tajemnic. Ale czy jesteśmy świadomi, dlaczego ich używamy? Aby pomóc zrozumieć ich istotę, krótko przypomnę, co się za nimi kryje i dlaczego są tak ważne w technikach zwinnych. Znajomość zwinnego planowania pracy jest kluczowa dla zrozumienia tego, jak unikać błędów w Agile. Na początek przyjrzyjmy się tzw. wydarzeniom, które pomagają stworzyć regularność i są pomyślane w taki sposób, aby zapewnić transparentność i umożliwić zweryfikowanie pracy zespołu na każdym etapie trwania projektu.

„Sercem Scruma jest Sprint” – trwający za każdym razem tyle samo etap, w trakcie którego zespół pracujący zwinnie dostarcza zadeklarowany Przyrost. Sam w sobie nie jest on określany jako wydarzenie, jednak składa się z nich – to pozwala na dobrą organizację pracy. Co i w jaki sposób zostanie dostarczone w danym Sprincie, zespół deweloperski ustala w trakcie Sprint Planningu. Aby zoptymalizować zaplanowaną w ten sposób pracę, stosuje się spotkania: Daily, Review oraz Retro. Daily Scrum pomaga członkom zespołu w utrzymaniu transparentności oraz w wychwyceniu potencjalnych problemów, Review zweryfikować, co zostało dokonane w trakcie określonego Sprintu, a Retrospective stanowi pole do przyjrzenia się temu, co w Sprincie poszło dobrze, a co wymaga poprawy. Brzmi prosto? Popularne powiedzenie głosi, że Scrum jest łatwy do zrozumienia, lecz trudny do wdrożenia. Sprawdźmy, jak to działa w praktyce i jakie są najczęstsze powody niezrozumienia idei zwinności.

Agile w praktyce – częste błędy

1. Niezrozumienie zasad

Zasady, na których opiera się Scrum, a które określa „Manifest Agile” wydają się proste, jednak większość osób na co dzień pracujących zwinnie może złapać się za głowę i stwierdzić: „U mnie to tak nie wygląda!”. Z mojego doświadczenia jako Scrum Master mogę przyznać, że o ile zasada dotycząca przedkładania ludzi i komunikacji nad procesy i narzędzia jest respektowana, o tyle pozostałe często stają się przedmiotem nieporozumień. Często niezrozumienie wynika z oczekiwań biznesu, dla którego istotne jest nie tylko otrzymanie działającego oprogramowania, ale także dokumentacji projektowej, a zwinne podejście bywa upraszczane do dostarczania przez zespół co 2 tygodnie paczki funkcjonalności. Błędna interpretacja podejścia zwinnego wynika z braku wiedzy wielu organizacji (zarówno polskich, jak i zagranicznych), jaka praca jest wykonywana po stronie zespołu deweloperskiego, aby dostarczana paczka spełniała wszystkie wymagania nie tylko pod kątem funkcjonalnym, ale również jakościowym czy bezpieczeństwa.

Zdarza się, że wiele pomysłów na działanie i usprawnienie pracy zespołów deweloperskich oraz respektowanie zasady „współpraca z klientem ponad formalne ustalenia” są blokowane przez ustalenia kontraktowe. Aby techniki zwinne pozwoliły wykorzystać w pełni potencjał zespołu, istotne jest zrozumienie ze strony biznesu, że zwinna organizacja zmierza do dostarczenia produktu najwyższej jakości w określonym czasie. Tu istotną rolę w każdym projekcie odgrywa Scrum Master/Agile Coach. To na jego barkach spoczywa edukowanie zarówno zespołu, jak i przedstawicieli biznesu.

2. Niezrozumienie zwinnej organizacji pracy

Innym problemem, który bardzo często pojawia się w przeróżnych projektach IT, jest podejście kaskadowe do poszczególnych artefaktów czy wydarzeń. Większość przedstawicieli biznesu nie zdaje sobie sprawy z tego, jak istotne jest Definition of Ready w kontekście docelowej dostarczalności zarówno całego produktu, jak i Incrementu czy pojedynczego zadania.
Zdarza się też tak, że Definition of Done jest niedoceniane jako gwarant jakości, a niejednokrotnie postrzegane jako przeszkoda w dostarczeniu paczki po Sprincie. Zdarza się także, że klient stara się wymóc na zespole deweloperskim dostarczenie jakiejś funkcjonalności szybciej, niż ten zaplanował w trakcie Sprint Planningu. Techniki zwinne ukierunkowane są na dostarczanie określonych Przyrostów w określonym czasie. To trochę tak jak z budową domu – nie zaczynamy jej od wyboru kolorów ścian, lecz planujemy etapami. Temu właśnie służą wspomniane przeze mnie spotkania: Sprint Planning, Daily, Retro i Review. Pozwalają one zaplanować pracę na poszczególnych etapach, nie wybiegając zbyt daleko w przyszłość i umożliwiając zespołowi skupienie się na danej czynności w danym czasie.

3. Niezrozumienie ról

Inną przyczyną niezrozumienia Agile jest błędne rozumienie ról w Scrumie, co może wynikać z kolei z niezrozumienia idei samozarządzającego się zespołu. Jako Scrum Master opowiem na przykładzie mojej roli, która często bywa błędnie pojmowana przez osoby spoza zespołu scrumowego. Bo jak może działać zespół bez lidera? Przecież jak świat światem zawsze istniały jednostki przywódcze, które brały na siebie odpowiedzialność za zarządzanie ludźmi. Rola Scrum Mastera bywa deprecjonowana do funkcji „Project Managera, który nie jest szefem” i pomijana przy tworzeniu zespołów („Przecież on nie dostarcza wartości, a w jego miejsce moglibyśmy zatrudnić jednego developera”). Czy to, że Scrum Master nie pisze kodu i nie testuje oprogramowania, oznacza, że jest zbędny? Nie. Scrum jest podejściem empirycznym, to znaczy opierającym się na doświadczeniu i komunikacji, a zadania Scrum Mastera są niemierzalne i zwykle polegają na uświadamianiu zespołowi deweloperskiemu zasad zwinnego funkcjonowania. Wartości roli Scrum Mastera nie widać nigdy w Burndown Charcie, ale jest ona zawsze widoczna w samym podejściu do pracy członków zespołu.

Podsumowanie

W technikach zwinnych każde wydarzenie, artefakt, spotkanie czy dyskusja mają znaczenie. Podejście zwinne, w każdym frameworku, nie tylko w Scrumie, to skomplikowany proces i sieć naczyń połączonych, gdzie każda akcja (lub jej brak) powoduje reakcję. Świadomość tego jest kluczowa dla zrozumienia idei zwinności. Podobnie bardzo istotne jest zrozumienie, że Agile nie kończy się na zespole deweloperskim, a przedstawiciele klientów oraz ich ustalenia kontraktowe mają bezpośredni wpływ na codzienną pracę zespołów scrumowych. Co więc można zrobić, żeby ten stan rzeczy zmienić? Komunikować się, reagować na zmiany, stawiać na pełną zrozumienia współpracę między klientem a zespołem deweloperskim. W ten sposób wracamy do podstaw Scruma, których stosowanie w praktyce jest idealną metodą na edukowanie zarówno zespołu, jak i partnera biznesowego. Jest to proces mozolny i długotrwały, ale w każdej organizacji IT pracującej zwinnie znajdziemy osoby (może nawet Agile Coachów?), które z chęcią wytłumaczą, dlaczego „zwinny” znaczy „inny” i jak z dobrodziejstw tej odmienności czerpać garściami.