5 Implikacji zarządzania wg Agile

Metodologia Agile jest wszędzie. Zwłaszcza w korporacjach, w których kiedyś królował Waterfall, Agile jest (czasami kompletnie bez sensu) wpychane drzwiami i oknami. Nowe projekty muszą być zwinne, menedżerowie muszą szybko nauczyć się operowania w zwinnym środowisku, a dostawcy odczuwają zwiększony popyt na Product Ownerów, SCRUM Masterów oraz developerów z doświadczeniem przy pracy w metodologii SCRUM lub Extreme Programming. Niekiedy zatrudniani są również Agile Coache, aby nieść sztandar zwinnego zarządzania projektami po całej firmie. Wszystko to w nadziei, że projekty przeprowadzone zostaną sprawniej i taniej. Ale o co w tym wszystkim chodzi?

Nie chcę się tutaj skupiać na opisie metody i rzeczach, które można wyczytać z Wikipedii. Wiele książek i publikacji scharakteryzowało tę metodę o wiele lepiej, niż ja będę kiedykolwiek w stanie to zrobić. Chcę się natomiast skupić na 3 poważnych implikacjach dla menedżerów, którzy z metodą są niezaznajomieni. Co konkretnie, praktycznie oznacza dla menedżera prowadzenie projektu zgodnie z metodyką Agile?

 

1. Partner do prowadzenia projektu

Nieodłączną cechą każdego dobrze (podkreślam to słowo) zarządzanego projektu Agile’owego jest osoba SCRUM Mastera. Jest to w dużym skrócie człowiek czuwający nad tym, aby projekt możliwie najlepiej i najefektywniej wykorzystywał założenia metodologii do osiągnięcia założonych celów.

SCRUM Master prowadzi spotkania (Planowanie Sprintu, Sprint Review, Demo, Retrospekcja), nadaje im ton i wykorzystuje dostępne narzędzia (a jest ich cała masa – choćby gry dotyczące retrospekcji czy słynny planning poker – fajna metoda szacowania złożoności zadania za pomocą kart), aby zespół dostał możliwie najlepiej położony grunt pod wykonywanie zadań założonych w określonym Sprincie.

SCRUM Master nie ingeruje w cele i wizję Product Ownera – jest bardziej pomocą, osobą, do której można (i trzeba) zwrócić się w razie problemów z zarządzaniem projektem czy zespołem. SCRUM Master NIE JEST konkurencją dla menedżera. Może (i powinien) być za to partnerem, który znacząco ułatwia pracę.

Warto jednak pamiętać, że o ile jeden projekt ma jednego Product Ownera, o tyle SCRUM Master może mieć wiele projektów na swoich barkach – toteż nie polecam zarzucać go masą problemów, których rozwiązanie nie leży w jego kompetencjach.

 

2. Zespół rozdziela zadania między siebie

Menedżerów, którzy nie mieli wcześniej do czynienia z metodyką Agile może zaskoczyć już pierwsze planowanie Sprintu. Jest ono znacząco różne od typowego planowania i delegowania zadań do wykonania. Rola Product Ownera redukuje się na takim spotkaniu do wyznaczenia celów do zrealizowania na najbliższe 2-3 tygodnie (czyli tyle, ile powinien trwać Sprint, chociaż warto dodać, że są od tego dobrze przemyślane wyjątki). Reszta jest w rękach zespołu i SCRUM Mastera.

Nie ma tu delegacji zadań. Zespół przegląda to, co jest do zrealizowania i z pomocą SCRUM Mastera (np. za pomocą rzeczonego planning pokera) dzieli się zadaniami pomiędzy sobą. To członkowie zespołu decydują, kto powinien być odpowiedzialny za jakie zadania, szacują ich trudność i raportują ich wykonanie. Co więcej – realnie Product Owner nie powinien mieć wpływu na to, jak pracuje zespół. Powinien jedynie pomagać w sytuacjach, które tego wymagają (np. w razie problemów zgłoszonych na daily (o tym zaraz), które wymagają interwencji).

Taki podział umożliwia Product Ownerowi silniejsze skupienie się na wizji i harmonogramie, a mniej na mikrozarządzaniu zespołem.

 

3. Dużo spotkań

Sercem każdego dnia powinno zawsze być DAILY, czyli krótkie (max. 30min, najlepiej sporo mniej), poranne (z reguły) spotkanie z zespołem (Product Owner + SCRUM Master + zespół + okazjonalnie inni zainteresowani), na którym poruszane są bieżące sprawy, raportowany jest przebieg prac i ewentualne problemu. Na każdym daily każdy członek zespołu odpowiada na trzy pytania:

  1. Co zrobiłem wczoraj?
  2. Co planuję zrobić dziś?
  3. Czy są jakieś problemy, które utrudniają mi wykonywanie zadań?

Daily to spotkanie, które odbywa się codziennie podczas trwania Sprintu. Sprint jednak trzeba najpierw zaplanować na Planowaniu Sprintu. Jest to dłuższe spotkanie, na którym Product Owner wskazuje, jakie zadania są do wykonanie w najbliższym czasie (jak wcześniej – optymalnie 2-3 tygodnie).

Sprint następnie należałoby formalnie zakończyć, spotykając się na Sprint Review (wewnętrzne spotkanie, na którym zespół prezentuje Product Ownerowi wyniki Sprintu) lub Demie (tak, jak Sprint Review, ale bardziej formalnie, przy dodatkowym udziale zainteresowanego biznesu i pod przewodnictwem Product Ownera).

Warto jeszcze pochylić się nad tym, jak wyglądała praca podczas Sprintu – służy do tego tzw. Retro, czyli spotkanie retrospekcja. Prowadzi je SCRUM Master, a jego zadaniem jest wykrycie i eliminacja przeszkód utrudniających zespołowi pracę tak, aby już nie przeszkadzały w kolejnych Sprintach.

Jest jeszcze Status z przedstawicielami biznesu i spotkania menedżerskie z wyższą kadrą w celu raportowania postępów. Ogólnie spotkań jest dużo, ale zdecydowanie mają one sens – w ten sposób wszyscy upewniają się, że projekt idzie zgodnie z planem.

 

4. Niepewność, dużo niepewności

Chcesz być Product Ownerem? Przygotuj się na robienie kilku harmonogramów. Marzysz o stałym zakresie, który raz zaplanowany będzie niczym wbity w kamień, a zespół będzie po kolei odhaczał kolejne wykonane zadania? Nic z tego. Zresztą, nie znam ani jednego projektu, który szedłby idealnie w ten sposób. Zawsze gdzieś wkradną się zmiany.

Agile zakłada przede wszystkim zmienność zakresu. To dlatego Sprinty trwają 2-3 tygodnie i dlatego jest zaplanowanych dużo spotkań. Kolejny Sprint może przynieść zupełnie nowy materiał, który wcześniej nie był nawet brany pod uwagę. Dlatego też Agile bardzo dobrze sprawdza się w projektach, których zakres nie jest w pełni znany, i które mogą wymagać pivotów podczas ich trwania.

Spotkania z biznesem to głównie cięcie, wykręcanie i operowanie na otwartym zakresie. To mnóstwo dyskusji o priorytetach, priorytetach pośród najwyższych priorytetów i dywagacje o wpływie wyrzucania lub dokładania funkcjonalności na realizację projektu.

Z punktu widzenia biznesu ma to również znaczne zalety. Każdy software ma bowiem swoje główne funkcjonalności, które następnie obudowane są trochę mniej ważnymi, ale bardzo przydatnymi z biznesowego punktu widzenia funkcjami. Jeśli są problemy z budżetem lub goni czas – ścinamy te mniej ważne i wypuszczamy produkt działający, ale okrojony. Wycięte z zakresu funkcje zrealizujemy po prostu w kolejncyh Sprintach.

 

5. Continuous Delivery, czyli stałe wypuszczanie produktu

To chyba najważniejsza cecha Agile. O ile Waterfall czy Prince2 zakładają wypuszczenie dopieszczonego, w pełni sprawnego produktu, o tyle Agile skupia się na czymś zupełnie przeciwnym. Metodologie zwinne to dostarczanie produktu jak najszybciej i jak najczęściej. Wypuść działający szkielet i buduj na nim nowe funkcje, a wyłapywanie błędów pozostaw członkom organizacji (testy FUT) lub biznesowi podczas testów UAT.

W Agile niegotowy produkt to nic strasznego. To okazja, żeby zebrać feedback i w kolejnym Sprincie wydać lepsze oprogramowanie. Widać to zwłaszcza w mniejszych firmach czy projektach IT, gdzie jeden Sprint potrafi być poświęcony na dostarczanie niesamowitej funkcjonalności, a drugi zawierać drobne poprawki i eliminację kilkunastu błędów – wszystko po to, aby trzeci znów wprowadził coś o dużej wartości dla użytkownika końcowego.

Osobiście uważam ten model prac za o wiele efektywniejszy, niż Waterfall. Z perspektywy Project Managera wspaniale widzieć jest, jak produkt rośnie z każdym Sprintem. Zwłaszcza w mniejszych firmach, gdzie praca jest bardziej startupowa, kolejne Sprinty potrafią stanowić gigantyczny krok naprzód.

 

Agile nie jest dla każdego, ale zdecydowanie warto dać tej metodologii szansę. Jest to też metodologia bardzo rozwojowa dla samego menedżera, która pozwala mu przyjąć trochę inne spojrzenie na skostniałe już problemy zarządzania projektami, z którymi musiał radzić sobie wcześniej. Zdecydowanie polecam!

Zapisz się do newslettera!

Dołącz do osób, które regularnie otrzymują ostre i kontrowersyjne treści, które z racji charakteru bloga nie nadają się do publikacji.
Tomek Opublikowane przez:

Jestem Scrum Masterem w branży e-commerce i zarządzam projektami IT dla klientów. Spełniam się też jako handlowiec i front-end developer. Zbieram zegarki, jaram się technologią i nauką (fizyka, astronomia, biologia). Potrafię uwarzyć własne piwo, zrobić sesję zdjęciową i tworzyć muzykę. Prowadziłem kiedyś bloga lifestylowego. Potem przestałem, żeby zacząć zarabiać pieniądze. Spełniłem swój cel i wracam do pisania.