Największy mit agile - szybciej, taniej, lepiej

Ogólnie dobrą wiadomością jest to, że w dzisiejszych czasach wszyscy jesteśmy zwinni. Złą wiadomością jest to, że ludzie próbują być zwinni, nie wiedząc często, co to tak naprawdę oznacza. Jednym z moich największych koszmarów jest mit szybszego, tańszego i przynoszącego lepszy rezultaty działania dzięki zwinności, a oto dlaczego...

Agile  -  Hasło świra z magiczną mocą dostarczania czegokolwiek w każdych warunkach.

Pochodzenie (本)

Historia Agile Manifesto jest dobrze znana w zwinnej społeczności. Niestety, niewiele osób słyszało o lean production lub lean manufacturing, która wyprzedza programowanie zwinne i miała na nie silny wpływ.

Wiele z praktyk zwinnego programowania jest opartych na lean manufacturing i obie metody mają podobną filozofię, która kładzie nacisk na ograniczenie marnotrawstwa. Te dwa podejścia różnią się pod względem wykonania, przede wszystkim dlatego, że lean manufacturing produkuje dobra fizyczne, podczas gdy agile opracowuje produkty cyfrowe.

Porównanie siedmiu rodzajów strat w lean production i zwinnym programowaniu

Dzięki ograniczeniu ilości marnotrawstwa, lean manufacturing produkuje towary o wyższej jakości przy niższych kosztach.

Co rodzi pytanie: "Czy zwinne programowanie nie jest szybsze, tańsze i nie przynosi lepszych rezultatów dzięki redukcji marnotrawstwa?".

Mit o szybszym, tańszym i lepszym wyniku

Tak, to prawda. Niestety, jeszcze łatwiej jest wykonywać czynności zwinne bez zmniejszania ilości marnotrawstwa.

Nigdy nie lekceważ potęgi myślenia życzeniowego. To jak przyklejenie naklejki Porsche na rower. QED.

Czasami zdarza się, że zespół lub scrum master są niedoświadczeni, więc będziesz chciał, aby przeczytali to i poszli na odpowiednie szkolenie.

W większości sytuacji interesariusze lub właściciele produktów nie rozumieją tak naprawdę konsekwencji zwinnego programowania. Często uważają, że agile jest czymś, co powinien zrobić zespół, podczas gdy oni mogą zachować status quo. Niestety, nic nie może być dalsze od prawdy.

Aby agile było skuteczne, interesariusze i właściciele produktów muszą zmienić swoje zachowania i zapewnić sprzyjające środowisko dla zespołu projektowego. Ewentualnie, powinny one po prostu trzymać się tradycyjnego modelu kaskadowego, ponieważ trzymanie się zwinności bez czerpania z niej korzyści jest czystą głupotą.

Teraz przedstawię siedem marnotrawstw do wyeliminowania.

1. Niedokończona praca (czyli praca w toku, WIP)

Mówimy tu o takich rzeczach, jak szczegółowa dokumentacja i wire-frame’y i nie mam na myśli częściowo wykonanej dokumentacji i wire-frame’ów. Odnoszę się do szczegółowej dokumentacji, wire-frame-ów i planów, które nie zostały jeszcze wdrożone jako kod. Dopóki nie zostaną one wdrożone jako działający kod, są WIP.

WIP pogarsza przełączanie między zadaniami, czas oczekiwania i łatwość wprowadzania zmian.

Niestety, człowiek pragnie pewności, a planowanie daje komfort. Niektórzy interesariusze i właściciele produktów wymagają większego komfortu niż inni.

Plany, dokumentacja i wire-frame-y są przybliżone, z różną dokładnością czekającą na wdrożenie.

Ilość marnotrawstwa, które można zmniejszyć, zależy od gotowości do podejmowania ryzyka przez zainteresowane strony. WIP to zło, którego nie da się uniknąć, więc staraj się je utrzymać na niskim poziomie.

2. Dodatkowe przetwarzanie

Oczywiście nie poświęcaj zbyt wiele czasu szlifowaniu proxy, takim jak plany, dokumentacja i makiety.

Niestety, gdy organizacje są zorganizowane jako grupy funkcjonalne, specjaliści funkcjonalni mają tendencję do nadmiernego przetwarzania, ponieważ są z tego rozliczani. Planiści są oceniani przez ich szczegółowy i wyczerpujący plan, analitycy biznesowi są mierzeni przez najgrubszą dokumentację dotyczącą ich potrzeb, a projektanci są... no wiesz o co chodzi. 

To systemowe marnotrawstwo nie może zostać wyeliminowane przez sprawny zespół projektowy. Wymaga to restrukturyzacji organizacyjnej przeprowadzanej przez kierownictwo wyższego szczebla, w celu dostosowania impulsów do całej organizacji.

3. Przełączenie między zadaniami

Kolejnym ubocznym efektem grup funkcjonalnych jest tendencja do przypisywania każdego specjalisty do wielu projektów, w celu ich pełnego wykorzystania.

Działania związane z dostarczaniem materiałów w formie cyfrowej mają charakter wysoce abstrakcyjny i wymagają kreatywności. Przełączanie się pomiędzy zadaniami wiąże się z marnotrawstwem z powodu przełączania kontekstu. Dodatkowe straty powstają w czasie zapisywania obecnego stanu, by móc go odtworzyć w przyszłości. Przerwanie i wznowienie pracy przy każdym przełączaniu zadań zajmuje około 15 minut.

Kolejną częstą przyczyną zmiany zadań są spotkania. Jeśli musisz mieć spotkania, zawsze przenoś je na początek lub koniec dnia, aby zminimalizować ilość marnotrawstwa dla całego zespołu. Należy rozumieć różnicę między czasem osoby tworzącej a menedżera.

Reagowanie na zmiany wymaga luzu. W pełni wykorzystana siła robocza jest antytezą zwinności, ponieważ wydłuża czas oczekiwania i opóźnienia.

4. Oczekiwanie / opóźnienia

Zbyt długie oczekiwanie często pojawia się, gdy product owner nie jest kolokowany z zespołem dostawczym. Zespół potrzebuje product ownera, aby wyjaśnić user stories i zatwierdzić ich pracę po jej zakończeniu. Czas oczekiwania może być nieproporcjonalnie długi, gdy zespoły są rozmieszczone w różnych strefach czasowych.

Utrudnia to zespołowi uzyskanie informacji zwrotnych od product ownera podczas retrospektywy oraz od innych interesariuszy podczas przeglądu sprintu. Brak lub powolne sprzężenie zwrotne oznacza brak, lub powolną poprawę, co powoduje trwałe wady i powtarzające się powtórki.

Spotkanie jest najczęstszą przyczyną opóźnień - znalezienie wspólnego przedziału czasowego, synchronizacja dostępności pomieszczeń i ludzi. Jeśli musisz mieć spotkania, tak je wykorzystaj.

5. Wady (i wynikające z tego przeróbki)

Im dłużej trwa wykrywanie wad, tym więcej ich powstaje i tym więcej marnotrawstwa powstaje w wyniku ich naprawiania.

Jedynym rozwiązaniem jest skrócenie pętli sprzężenia zwrotnego i wczesna korekta. Codzienny stand-up, przegląd sprintu i retrospektywa to najlepsze sposoby uzyskania informacji zwrotnej, usunięcia usterek i wspólnego napędzania postępu.

Niestety, sesje te często nie są w pełni wykorzystywane. Zespół potrzebuje bezpiecznego środowiska do dzielenia się krytycznymi i konstruktywnymi informacjami zwrotnymi, aby poprawić jakość swojej pracy. Product owner musi uczestniczyć i współtworzyć tę bezpieczną przestrzeń.

6. Przekazanie zadań

Podobnie jak w przypadku pracy częściowo wykonanej, dodatkowego przetwarzania i przełączania zadań, przekazanie zadań często wynika ze struktury organizacji.

Wiedza jest tracona za każdym razem, gdy efekt prac lub artefakt jest przekazywany między rolami. Powoduje to dłuższe opóźnienie i większą ilość wad, i to o rząd większe niż w przypadku przekazywania fizycznych towarów. Przy pracy cyfrowej głupotą jest ponoszenie kosztów związanych z przekazywaniem zadań na rzecz szerszego wykorzystania pracowników.

7. Nadprodukcja

Nadprodukcja ma na celu rozwój funkcji, które nie są potrzebne użytkownikom. Najlepszym sposobem na uniknięcie nadprodukcji jest zbudowanie najmniejszej możliwej funkcji  lub produktu (MVP) i zweryfikowanie hipotezy przed zbudowaniem jej większej i lepszej wersji.

Niestety nadprodukcja często wynika z arogancji product ownerów i innych interesariuszy. Często są zbyt pewni swojego pomysłu, że decydują się na pominięcie MVP i zainwestowanie w pełnowartościowy produkt.

Spośród wszystkich marnotrawstw nadprodukcja jest najgorsza, ponieważ pociąga za sobą wszystkie inne straty.

Podsumowanie

Zwinne rytuały i praktyki inżynieryjne są jak najbardziej przydatne i mogą znacznie pomóc Twojemu zespołowi udoskonalić swoją pracę. Niestety jednak, poprawa wyników zespołu może zawsze uderzyć o ścianę z powodu przeszkód, na które zespół nie ma wpływu.

Przeszkody te znane są również pod nazwą wastes (marnotrawstwo) - zapożyczone z lean manufacturing. Wynikają one z nadmiernego planowania, funkcjonalnej struktury organizacyjnej, niedostępności product ownera, nadmiernych spotkań, braku bezpiecznego środowiska dla krytycznej i konstruktywnej informacji zwrotnej oraz arogancji produktu przez HiPPO.

Niespodzianka! W agile nie ma nic magicznego. Agile uwidacznia te marnotrawstwa, dzięki czemu właściciele produktów i zainteresowane strony mogą je wyeliminować. W przeciwnym razie to tylko kolejny fantazyjny pomysł, który wytwarza więcej hałasu niż efektów.

Mam nadzieję, że ten artykuł poszerzy Twoją perspektywę na to, co jest ważne w agile i dlaczego działa.


Oryginalny tekst w języku angielskim przeczytasz tutaj.