Mity na temat Agile, część 2

Niedawno obchodziliśmy kolejną rocznicę powstania Agile Manifesto. W lutym 2001 roku podczas narciarskiego wyjazdu w góry Utah powstał manifest, który zrewolucjonizował podejście do zarządzania. W ciągu 21 lat swojego istnienia, na temat zwinności powstało wiele mitów, z którymi postanowiliśmy się rozprawić w naszych artykułach. Na naszym blogu pojawiło się już 5 najczęściej powtarzanych mitów na temat Agile, dziś rozwiejemy kolejne wątpliwości dotyczące tego tematu.

1. Agile to metodyka

Przyjrzyjmy się przez chwilę definicji słowa “metodyka”. Według Uniwersalnego Słownika Języka Polskiego „Metodyka to zbiór zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu”. Metodyka opisuje jak krok po kroku wykonać jakąś czynność lub zrealizować zamierzony plan.

Agile nie jest metodyką, ale filozofią pracy, zbiorem wytycznych. Autorzy wskazują jedynie cztery podstawowe wartości oraz dwanaście zasad, jakimi kierują się podczas pracy. Agile można jednak uznać za “słowo-parasol”, pod którym chowają się różne metodyki zwinnego zarządzania zespołem czy projektami.

2. Waterfall jest zawsze zły

Chociaż podejście zwinne powstało w kontrze do kaskadowego modelu pracy, to nie oznacza to, że dobrze znany i przez lata stosowany Waterfall zawsze wypadnie gorzej niż zarządzanie zgodne z pryncypiami Agile.

Co do zasady, na świecie nie istnieją rozwiązania idealne oraz takie, które do niczego się nie nadają. To, jaki model powinno się zastosować w pracy zależy od tego, jakie zadania w niej wykonujemy oraz jakie efekty chcemy osiągnąć. Jeżeli nasze zadania są proste do zaplanowania, wiemy jaki efekt chcemy uzyskać i jak to zrobić, a przy tym istnieje niewielkie prawdopodobieństwo potknięcia się i pomyłek – nic nie stoi na przeszkodzie, aby przeprowadzić ten proces tradycyjną metodą.

Podejście zwinne sprawdza się w sytuacjach, gdy “nie wiemy, czego nie wiemy”, zmienne są zaskakujące, tak samo jak wyniki pracy. Jeżeli rezultaty są powtarzalne, nie ma w nich miejsca na personalizację i niewiele może Cię zaskoczyć, Waterfall może nie być złym pomysłem.

3. W zwinnym zespole każdy robi, co mu się podoba

Prawda jest zupełnie odwrotna – dobrze działający Agile potrzebuje znakomicie zorganizowanych zespołów, a właściwie zespołów samoorganizujących się. Co to oznacza?

Samoorganizujący się zespół działa sam – nie zależy od menedżera, nie czeka na rozdysponowanie zadań, ale potrafi odnaleźć się w swoim środowisku i odpowiednio pokierować swoją pracą. 

To właśnie we wspólnej, zaangażowanej pracy tkwi natura zwinności. Każdy w zespole powinien być gotowy do pomocy współpracownikom oraz podnoszenia swoich kompetencji, które pozwolą na sprawniejsze działanie ogółu. I choć z zewnątrz praca zwinnego zespołu może wydawać się nieskoordynowana – przecież nikt niczego nie “rozkazał”, ani nie rozdzielił zadań, to dobrze dobrane zespoły doskonale wiedzą, w jaki sposób najlepiej wykonywać swoją pracę.

4. Agile działa tylko w małych organizacjach

Nie da się zaprzeczyć, że Agile działa najlepiej w małych zespołach, jednak nie oznacza to, że wdrożenie go do większej organizacji jest niemożliwe! Oznacza to jednak, że zmianę należy rozpocząć od jej najmniejszych komórek. 

Wyobraź sobie sytuację, w której pewnego dnia stwierdzasz, że cała Twoja firma przestaje korzystać ze skrzynki na Gmailu i przenosi się na Outlooka. Nawet tak mała zmiana spowoduje chaos, a co dopiero transformacja całego sposobu zarządzania organizacją! 

Tak jak wspominaliśmy, Agile nie jest metodologią, to znaczy, że nie pokaże Ci dokładnej drogi, nie przeprowadzi przez proces krok po kroku, a jedynie wskaże wartości i priorytety. Aby ten system zadziałał, ważne jest, aby każdy członek zespołu się z nimi identyfikował. 

Zwinność najlepiej implementować do małych zespołów, małych projektów, w których najłatwiej zauważyć pojawiające się problemy. Zmiany wprowadzaj małymi krokami – komórka po komórce.

5. W Agile nie ma lidera

To częsty mit, który wynika z faktu, że większość organizacji zarządzanych zwinnie stara się utrzymywać możliwie najbardziej płaską strukturę organizacyjną, a słowo “lider” jest błędnie interpretowane.

W najbardziej popularnym agilowym frameworku – Scrumie, próżno szukać stanowiska zatytułowanego “lider”. Mamy Development Team, Product Ownera i Scrum Mastera. Jednak, gdy wczytamy się głębiej w Przewodnik po Scrumie zobaczymy, że Scrum Master utożsamiany jest z hasłem “Servant Leader” (Przywódca Służebny). 

Jego rolą jest motywowanie, pomoc w rozwoju oraz wspieranie procesów i ludzi. Buduje zespół i wyciąga z niego to, co najlepsze. 

Częstym błędem jest stawianie znaku równości między słowem “lider” a “przełożony”. Czymś innym jest przewodzenie, a czymś innym rozkazywanie. Servant Leader wskazuje kierunek, zamiast do niego popychać, zachęca do działań, jednak do nich nie zmusza, ufa zespołowi i stara się usuwać przeszkody, które uniemożliwiają osiągnięcie zakładanych celów. 

Nie należy go utożsamiać z “tradycyjnym” menedżerem, który jest kontrolerem i egzekutorem zobowiązań.

* * *

Jak mówią – w każdej legendzie jest ziarenko prawdy, a każdy mit wynika z pewnego niezrozumienia. Mamy nadzieję, że przynajmniej niektóre nieporozumienia udało nam się w naszych ostatnich artykułach wytłumaczyć.

Macie inne wątpliwości dotyczące zwinności? Podzielcie się nimi w komentarzu!

Dodaj komentarz

jedenaście + sześć =