5 najczęstszych problemów w pracy z agilem – perspektywa Project Managera vs. programisty

Agile nie jest narzędziem ani metodyką, a filozofią i stylem pracy, która, jeśli jest dobrze zrozumiała i odpowiednio wspierana pozwala na inkrementalne dostarczanie oprogramowania szybciej, efektywniej i zawsze zgodnie z oczekiwaniem Klienta. 

Ponieważ zmiana sposobu myślenia jest zależna od osób, które uczestniczą w zwinnym wytwarzaniu oprogramowania, możemy napotkać na problemy w niewystarczającym zrozumieniu wartości Agile zarówno na poziomie współpracy z Klientem, jak i w codziennej pracy zespołu developerskiego z Project Managerem. 

Perspektywa problemów jest inna z punktu widzenia Project Managera zarządzającego projektem oraz Developera, który w nim uczestniczy, ale zawsze ich rozwiązanie wymaga współpracy dwóch stron z takim samym zaangażowaniem i chęcią zmiany, a niejednokrotnie owe rozwiązanie przynosi również korzyść Klientowi.

Do 5 najczęstszych problemów identyfikowanych podczas zwinnego dostarczania oprogramowania jak i pracy w Agile są:

  • Niska świadomość zwinności – Czy zespół i Klient mają wystarczającą wiedzę, aby potrafić pracować w zwinnym sposobie pracy? 

  • Brak sprecyzowanej i zrozumiałej potrzeby biznesowej – Czy wszyscy wiemy po co realizujemy dany produkt?

  • Brak komunikacji – Jak bardzo potrzebna jest częsta interakcja z Klientem i po co komunikujemy się w zespole? 

  • Unikanie odpowiedzialność – Czy identyfikujemy się z naszą pracą i potrafimy być za nią odpowiedzialni?

  • Brak elastyczności w stosowaniu zwinnych narzędzi – Czy jeśli coś nie działa możemy coś zmienić? 

1. Niska świadomość zwinności

Zwinność trzeba zrozumieć, nie da się jej zastosować jako narzędzie do pracy czy schemat prowadzenia prac nad produktem. Kluczowe jest postępowanie zgodnie z wartościami Agile, które określają styl i sposób dostarczania oprogramowania. 

Częstym problemem jest brak świadomości Klienta i osób bezpośrednio zaangażowanych w dostarczenie produktu jak pracować zwinnie, jakie wartości niesie za sobą Agile i jak ich zrozumienie może wpłynąć na szybkość, jakość i wartość dostarczanego rozwiązania. Zdarza się również, że Klient deklaruje znajomość Agile na etapie podpisania umowy i definiowania wymaga, ale podczas prac okazuje się, że oczekuje innych rezultatów i zmienia swoje podejście. 

Z punktu widzenia Project Managera zwinność ma pomagać w dostarczaniu produktu i powinien on zwrócić szczególną uwagę na prowadzenie projektu zgodnie z jej założeniami, nie próbując za wszelką cenę ingerować w pracę zespołu, wyznaczanie zadań, ograniczanie komunikacji między zespołem, a Klientem oraz wymaganie szczegółowych raportów postępów prac. Praca zwinna jest transparentna, więc postęp prac powinien być znany dla wszystkich zainteresowanych stron. Sam Project Manager powinien cechować się wiedzą z zakresu zwinnego dostarczania oprogramowania i posiadać doświadczeniu w prowadzeniu takich projektów. W razie potrzeby wspólnie z zespołem powinien również edukować i pomagać Klientowi w zrozumieniu zwinności. 

Z punktu widzenia Developera kluczowe wartości Agile powinny być przez niego zrozumiałe i akceptowane. Sposób dostarczania produktu powinien opierać się na rozumieniu potrzeb klienta, przyrostowemu dostarczaniu oprogramowania na czas, współpracy zarówno z Klientem jak i z zespołem, dbaniu o jakość dostarczanego rozwiązaniu oraz ciągłej komunikacji i informowaniu o pojawiających się problemach. 

Powinniśmy upewnić się czy Agilowy sposób pracy jest dla wszystkich zrozumiały i czy postępowanie według filozofii Agile jest przez nas akceptowane. Kiedy zidentyfikujemy potrzebę wyjaśnienia zasad i reguł warto przeprowadzić z Klientem i zespołem warsztat, którego celem będzie wyjaśnienie filozofii Agile, symulacja pracy i pokazanie wartości jakie ta praca przyniesie. Tylko wtedy można osiągnąć pełne zrozumienie na każdym etapie wytwarzania oprogramowania i uniknąć błędów w implementacji zwinności w konkretnym projekcie. Dodatkowo na etapie podpisywania z Klientem umowy Agile warto wyjaśnić jej każdy punkt oraz podać przykład jak będzie on wyglądał w rzeczywistości. Tylko wtedy uzyskamy gwarancję pełnego zrozumienia sposobu dostarczania projektu.
Ważną postacią jest Scrum Master lub Agile Coach, których rolą jest edukowanie, podtrzymywanie pracy zgodnie z Agile i dbanie o to, aby była ona efektowana. Korzystanie z ich pomocy na każdym etapie dostarczania, pomoże poprowadzić projekt zgodnie z filozofią Agile.

2. Brak sprecyzowanej i zrozumiałej potrzeby biznesowej

W zwinnym dostarczaniu oprogramowania podstawowym błędem jaki popełniany już na wstępnej analizie potrzeb Klienta, a później w procesie dostarczania jest brak odpowiedzi na podstawowe pytanie “Po co to robimy?”. 

Potrzeba biznesowa produktu to nic innego jak sprecyzowany cel lub odpowiedz na powstały problem, dla którego nasz Klient zdecydował się na wytworzenie lub modyfikacje produktu. Określa najważniejsze funkcjonalności z punktu widzenia zarówno Klienta jak i użytkowników końcowych, problemy jakie istnieją lub z jakimi trzeba się zmierzyć i wartość jaka zostanie dostarczona z chwilą uruchomienia oprogramowania. Może nią być m.in. wprowadzenie innowacji, ograniczenie kosztów, poprawa jakości i wydajności, skrócenie czasu lub zadowolenie użytkowników. 

Określenie i zrozumienie potrzeby biznesowej Klientów, z którymi wspólnie dostarczamy produkty jest trudne zarówno na poziomie jej kreowania jak I w późniejszym procesie dostarczania produktu. Często jej niedoprecyzowanie, nieodpowiednie przekazanie lub pominięcie w procesie wytwarzania oprogramowania prowadzi do sytuacji, kiedy produkt nie spełnia podstawowych założeń, Klient jest niezadowolony z efektów, a zespół traci motywację do dalszej pracy. Wielokrotnie zdarza się również, że podczas definiowania wymagań jakie powinien spełniać produkt zapomina się o określeniu potrzeby biznesowej, a tym samym celu realizacji produktu.  

Z punktu widzenia Project Managera potrzeba biznesowa jest celem projektu i jego zadaniem jest przekazanie zespołowi jej założeń oraz monitorowanie czy aktualna realizacja zmierza do osiągnięcia potrzeb biznesowych Klienta. Na poziomie zarządczym postępy dążenia do osiągniecia potrzeby biznesowej powinny wyznaczać sukces lub porażkę realizacji projektu. 

Z punktu widzenia Developera potrzeba biznesowa określa zakres funkcjonalności lub specyficzne wymagania, które powinny zostać dostarczone jako pierwsze, w określnym czasie, aby spełniały zapotrzebowanie Klienta i przynosiły maksimum wartości przy zachowaniu należytej jakości inkrementalnego dostarczania produktu.  

Potrzebę biznesową należy zdefiniować wspólnie z Klientem w pierwszym etapie współpracy na poziomie badania potrzeb Klienta. Rolą Project Managera i Zespołu Developerskiego jest pomoc Klientowi w jej zdefiniowaniu, jeśli jest niewystarczająca, przygotowanie realizacji produktu zgodnie z jej wartościami oraz częste monitorowanie czy jest on zgodny z potrzebą biznesową Klienta. Zespół Developerski podczas definiowania celów poszczególnych inkrementów powinien podążać za celem nadrzędnych produktu, czyli potrzebą biznesową jego wytworzenia i sugerować Klientowi zmianę wymagań, tak by zmierzały one do jej osiągnięcia. 

3. Brak komunikacji

Brak komunikacji i współpracy na całym etapie wytwarzania produktu ze wszystkimi, którzy w nim uczestniczą nie pozwala pracować zwinnie, ponieważ powoduje, że zmiana wymagań, dostosowywanie produktu zgodnie z jego aktualnymi potrzebami oraz bieżące reagowanie na powstałe problemy nie odbywa się, co uniemożliwia dostarczenie go szybko i zgodnie z wizją Klienta.  

Często zdarza się, że zespół rozmawia ze sobą tylko podczas codziennych spotkaniach Daily Scrum, a resztę dnia poświęca na programowanie pracując w swojej własnej przestrzeni i nie czuje potrzeby komunikowania się z Klientem i rozmowy na temat dostarczanej funkcjonalności. W momencie napotkania problemów, nie komunikuje ich innym członkom zespołu, próbując rozwiązać wszystko samodzielnie. Dodatkowo Project Manager dowiaduje się ostatni o zaistniałych blokerach, co uniemożliwia szybką reakcję na powstały problem i jego rozwiązanie, a tym samym Klient informowany jest po czasie, co powoduje, że prace wydłużają się, problemy nawarstwiają, a atmosfera w zespole powoduje konflikty i niedomówienia. 

Praca w Agile opiera się częstej komunikacji i współpracy zarówno z Klientem jak i wewnątrz zespołu, który dostarcza produkt. Jest kluczowa i powinno się zadbać o nią na każdym etapie dostarczanego produktu. Częste spotkania, rozmowy z Klientem i weryfikacja wymaga odwagi, zrozumienia potrzeby komunikowania się i współpracy, otwartości, szczerości oraz aktywnego słuchania. 

Z puntu widzenia Project Managera ważne jest, aby zadbał on o częsty feedback od zespołu i wspólnie pracował z nim, aby śledzić pojawiające się problemy. Jest on wsparciem dla zespołu w kontaktach z Klientem i pomaga w odpowiednim przepływie informacji oraz negocjacjach, wtedy, gdy zespół nie może poradzić sobie sam. Dodatkowo on sam powinien mieć bardzo dobrze rozwiniętą umiejętności komunikacji i słuchania innych. Ważne jest również, aby Project Manager wraz ze Scrum Masterem i Product Ownerem zadbał o dostosowanie komunikacji do indywidualnych potrzeb członków zespołu oraz przygotował na pierwszym etapie projektu plan komunikacji wraz z rolami członków zespołu i odpowiedzialnościami, miejscami, gdzie będzie odbywać się komunikacja oraz narzędziami do tego używanymi. 

Z punktu widzenia Developera ważne jest szybkie komunikowanie zaistniałych problemów na każdym etapie wytarzania oprogramowania, umiejętność proszenia o pomoc innych członków zespołu, częsta komunikacja z Klientem oraz postępowanie zgodnie z ustalonym planem komunikacji używając do tego wszystkich możliwych narzędzi jak telefon, e-mail, wirtualne komunikatory, przestrzenie dedykowane do dokumentowania pracy i aktywności projektowych oraz inne usprawniające przepływ informacji. 

Włączenie Klienta w proces komunikacji wewnątrz projektu pozwoli wszystkim uczestniczącym w nim stroną na ciągłe udoskonalanie dostarczanego produktu, szybkie rozwiązywanie pojawiających się problemów oraz podążanie za wizją i potrzebą biznesową. Częsta komunikacja przejawiająca się w licznych spotkaniach, konferencjach telefonicznych i aktualnego wirtualnego miejsca przechowywania informacji projektowych pozwoli uczestnikom projektu na przekazywanie informacji, wyrażanie swoich opinii lub wątpliwości, które pozwolą podejmować najlepsze decyzje, motywowanie innych do działania i kontrolę nad wszystkimi aspektami dostarczanego rozwiązania. 

4. Unikanie odpowiedzialności

Brak poczucia odpowiedzialności za wykonywaną pracę jest kolejnym źródłem niedostarczania produktu na czas, w określonym budżecie i zgodnie ze ustalonymi wymaganiami. W konsekwencji zespół projektowy czuje frustracje i nie bierze odpowiedzialności za efekty swojej pracy. Przyczyn unikania odpowiedzialności może być wiele zaczynając od osobistych problemów członków zespołu, brak identyfikacji z projektem lub/i zespołem, czy potoczne stwierdzenie, że za projekt odpowiedzialny jest Project Manager, a pozostali uczestnicy wykonują jedynie zlecone im zadania. 

W zwinnych zespołach bardzo ważne jest utrzymanie samoorganizacji oraz dojrzałości jego członków na takim poziomie, aby odpowiedzialność za wykonywaną pracę była motorem do działania i pozwalała na swobodę w realizacji projektu. 

Z punktu widzenia Project Managera musi on pozwolić członkom zespołu wziąć odpowiedzialność za wykonywana pracę i pozwolić im na samoorganizację wewnątrz zespołu, a tym samym obdarzyć ich wysokim zaufaniem. Bez tego zespół będzie jedynie spełniał polecenia i wykonywał zadania nie identyfikując się z nimi, a tym samym zwinne podejście nie będzie realizowane. Wspólnie ze Scrum Masterem powinien obserwować organizację zespołu, nie ingerować w ich pracę, a jedynie wspierać i pomagać rozwiązywać zaistniałe problemy. To Project Manager wspólnie z Product Ownerem odpowiadają na pytanie “Co będziemy robić” wielokrotnie wspólnie z pomocą zespołu i Klienta, natomiast “Jak to będzie zrobione” pozostaje tylko w gestii zespołu, a tym samym pozwala im wziąć na siebie odpowiedzialność za podejmowane decyzję, prace projektowe i organizacje wewnątrz zespołu. 

Z punktu widzenia Developera powinien on przede wszystkim dążyć do tego, aby, środowisko pracy opierało się na wzajemnym zaufaniu i akceptacji popełnianych błędów. Powinien mieć możliwość otwartej dyskusji, wyrażania swojego zdania i pracy według zasad ustalonych wspólnie z członkami projektu. Musi dodatkowo wiedzieć, że odpowiedzialność za sukces lub porażkę całego projektu w zwinnym środowisku ponosi cały zespół, a jego praca składa się na efekty realizacji.  

Zrozumienie na czym polega odpowiedzialność za swoją pracę, a tym samym odpowiedzialność za efekty, wyniki i identyfikacja z zadaniem ułatwia codzienną pracę i ma kluczowe znaczenie w realizacji. Pozwala na posiadanie wpływu na efekt końcowy, wzrost zaangażowania oraz pełne zaufanie wewnątrz projektu. Dodatkowo Scrum Master wspiera zespół w stawaniu się samoorganizującym się, uświadamia jak ważną rolę odgrywa odpowiedzialność w zwinnych projektach i pomaga w jej osiągnięciu.

5. Brak elastyczności w stosowaniu zwinnych narzędzi

Kiedy zapada decyzja o tym, że projekt będzie realizowany zwinnie bardzo często zdarza się, że po wyborze metodyki pracy zespoły nie dokonują żadnych modyfikacji zarówno samej metodyki jak i narzędzi wykorzystywanych do zwinnego pracy w projekcie uznając, że wybrana metodyka nie pozwala na elastyczność. Istnieje przekonanie, że należy postępować według wytycznych “by the book” co jest sprzeczne z jedną z wartości Agile jaką jest otwartość. Otwartość na zmianę nie dotyczy jedynie technicznych aspektów pracy, ale całościowego spojrzenia na środowisko pracy i narzędzi wykorzystywanych do jej monitorowania. Jeśli zdarza się, że jakaś aktywność nie przynosi spodziewanych efektów należy zastanowić się nad tym, dlaczego tak się dzieje, spróbować rozwiązać problem poprzez edukowanie i pokazywanie jej wartości, ale również możliwa jest zmiana lub wdrożenie nowych narzędzi zapobiegających powstawaniu problemu.  

Zmiana metodyki w trakcie trwania projektu jest również dopuszczalna pod warunkiem, że przyniesie ona korzyści w postaci dostarczania produktu. Jeśli używany dotychczas Scrum w projekcie, nie jest odpowiedni do specyfiki projektu możemy w trakcie projektu zastąpić go np. Kanbanem lub wprowadzić inne narzędzia zwiększające monitorowanie postępów prac i pomagające w ich realizacji, aby zachować tak ważną w zwinności transparentność prac. Wszystko zależy od pojawiających się problemów, ale ważne jest, aby zarówno zespół, Scrum Master, Product Owner i Project Manager wspólnie z Klientem byli uważni na otoczenie projektowe i wspólnie znajdowali nowe drogi w rozwiązywaniu problemów projektowych z zachowaniem elastyczności w swoich działaniach. 

Z punktu widzenia Project Managera powinien on zaakceptować i pozwolić na stosowanie różnych narzędzi zwinnych w projekcie, które zwiększają transparentności wykonywanych prac, pomogą dostarczyć produkt szybciej, wyższej jakości, poprawią komunikację i zaangażowanie oraz skalowalność projektu. Powinien on również wspierać zespół i przy współpracy Scrum Mastera wspólnie proponować nowe rozwiązania i narzędzia, w momencie, gdy obecne stają się niewystarczające. 

Z punktu widzenia Developera ważne jest, aby informował o pojawiających się problemach, które dotyczą pracy z narzędziami projektowymi, proponował użycie i zastosowanie ich, ale również używał do codziennej pracy i rozumiał potrzebę zasadności ich użycia. Zespół Developerski powinien dostosować narzędzia pracy do specyfiki projektu i jego wymagań, tak aby były one pomocne dla każdego uczestnika projektu, a ich użycie nie było czasochłonne i nie przysłaniały zwinnej idei ludzie i iteracje ponad procesy i narzędzia. 

Każda zmiana w projekcie i jego otoczenia wymaga rozważności, aby nie doprowadzić do sytuacji, gdzie mówimy jedynie o prowadzeniu projektu zwinnie, natomiast jego wewnętrzne środowisko jest identyczne jak w metodykach kaskadowych. Elastyczność w stosowaniu narzędzi zwinnych jest ważna na każdym etapie, ale powinna zostać ograniczona do wartości Agile, które pozwalają na dostarczanie produktu zgodnie z jej ideologią. Eksperymentowanie z użyciem różnych narzędzi projektowych i różnych zwinnych metodyk prowadzenia projektu pozwala jego uczestnikom na zdobycie nowych doświadczeń, a niejednokrotnie na efektywniejszą pracę i szybszą realizację.

Przedstawione powyżej problemy mogą zaistnieć w projekcie równocześnie lub pojedynczo. Ważne jest, aby nie ignorować ich, a wspólnie ze wszystkimi uczestnikami projektu otwarcie o nich rozmawiać i znajdować drogi do ich rozwiązania. Zrozumienie filozofii zwinnego dostarczania oprogramowania wymaga czasu i ciągłej, nieprzerwanej poprawy pracy, identyfikacji przeszkód i szukania możliwie najlepszych dla wszystkich metod przynoszących pomyślne zakończenie projektu.  

Każdy realizowany projekt IT powinien zostać dostarczony bazując na zrozumieniu zwinnego dostarczania oprogramowania zarówno zespołu deweloperskiego jak i Klienta, zgodnie z wymaganiami Klienta, podążając za jego potrzebą biznesową, w ścisłej i codziennej współpracy wszystkich zaangażowanych uczestników projektu, przy użyciu najlepszych rozwiązań, metodyk i narzędzi odpowiednich do specyfiki danego projektu oraz przy zaangażowaniu i wysokiej odpowiedzialności jego uczestników.  

Perspektywa uczestników projektu zawsze będzie się różnić w wielu aspektach, ale istotne jest, aby wspólnie dążyć do osiągania konsensusów i rozwiązywać pojawiąjące się problemy w codziennej pracy zaraz po ich wystąpieniu, a najlepiej być na tyle uważnym by nie dopuszczać do ich powstania. Za te wszystkie działania odpowiedzialni są w takim samym stopniu Klient, Project Manager, Product OwnerScrum Master i cały Zespół Deweloperski. 

About the Author: Justyna Zalewska

Justyna Zalewska

Over 11 years of professional experience in solutions delivery in production & IT areas including leadership experience during all phases of Product Lifecycle Management process.

Oversees the planning, development, implementation and maintenance of manufacturing, and project methods, processes, and operations for new and existing products.
Justyna is salso a coach and trainer in the Project Management methodologies and soft skills.

Read the articles:

Let’s talk about the digital sustainability in your company!

2019-09-15T22:46:18+00:0015 września, 2019|Uncategorized|0 Comments

Leave A Comment