Prowadzenie projektów na wdrożenie systemów informatycznych zgodnie z filozofią Agile miało stanowić remedium na problemy charakterystyczne dla projektów prowadzonych zgodnie z metodykami kaskadowymi, takimi jak źle oszacowany czas i koszty wdrożenia. Ich występowanie powodowało często konieczność wielokrotnego aneksowania umowy lub toczenia sporów o zakres i nieterminowość prac. Realizowanie projektów przy podejściu agile’owym miało też zapewnić lepsze dopasowanie finalnego systemu do zmieniających się potrzeb zamawiającego, dzięki możliwości szybkiej reakcji w razie pojawienia się konieczności modyfikacji projektu.

Z takim podejściem projektowym wielu zamawiających wiązało nadzieję, że projekty będą realizowane sprawniej, taniej i bardziej efektywnie niż projekty prowadzone przy podejściu kaskadowym.

Niestety, wraz z rosnącą w Polsce popularnością podejścia agile’owego zwiększa się również wolumen nieudanych wdrożeń prowadzonych zgodnie z tą filozofią. W konsekwencji pociąga to wzrost liczby sporów dot. realizacji umów na projekty zwinne.

Niewątpliwie, warunkiem koniecznym dla prawidłowości przebiegu projektu agile’owego jest dojrzałość organizacji (zwłaszcza zamawiającego) oraz specjalistów zatrudnionych do realizacji projektu w sposób zwinny. Dojrzałość ta polega na kompleksowym zarządzaniu projektem tak, aby nie utracić z pola widzenia jego celu, czyli stworzenia systemu zgodnego z potrzebami zamawiającego, ale również kontroli budżetu, tj. finalnej wysokości wynagrodzenia dla wykonawcy za całe wdrożenie oraz elementów, które w ramach poszczególnych timeboxów/sprintów odbiera zamawiający. W praktyce bowiem okazuje się, że prowadząc projekt agile’owy i koncentrując się na dostosowywaniu prac wykonawcy do zmieniających się potrzeb zamawiającego, strony „zapominają” o kontroli wykorzystania budżetu, znaczeniu odbiorów poszczególnych etapów oraz wyszczególnieniu, co wchodzi w ich zakres.

Brak kontroli nad projektem może również skutkować wątpliwościami na gruncie praw własności intelektualnej uzyskanych przez zamawiającego. W praktyce strony mogą mieć wątpliwości co do zakresu praw intelektualnych przeniesionych przez wykonawcę na zamawiającego w przypadku, gdy dojdzie do zerwania współpracy pomiędzy stronami przed pierwotnie zakładanym terminem, co często wiąże się z brakiem zapłaty przez zamawiającego wynagrodzenia za część prac, przy jednoczesnym zastrzeżeniu w umowie, że majątkowe prawa autorskie do danych elementów systemu przechodzą na zamawiającego z momentem zapłaty. Ustalenie, do których elementów zamawiający nabył prawa, jest bardzo trudne bez wiedzy, za które elementy zamawiający zapłacił. Zamawiający znajduje się wówczas w sytuacji, w której nie wie, czy może legalnie korzystać z dostarczonych mu utworów.

Równie problematyczną może okazać się kwestia rentowności prac wykonywanych w modelu zwinnym. Bowiem częsta aktualizacja wymagań co do zakresu funkcjonalności zazwyczaj przekłada się na zwiększenie ilości prac w projekcie, a w konsekwencji – na konieczność zapłaty przez zamawiającego wyższego wynagrodzenia. 

Wobec powyższego, bazując na doświadczeniach w obsłudze prawnej projektów prowadzonych zwinnie oraz znajomości sporów, jakie im towarzyszą, można rekomendować zamawiającym, którzy decydują się na projekty realizowane w sposób zwinny, aby dokładnie monitorowali i archiwizowali informacje na temat dostarczanych produktów (w tym ich jakości i terminu dostarczenia), a także pamiętali o elemencie finansowym i biznesowym w toku produkcji. Nawet najlepszy, w ocenie osób projektowych, system może nie zostać sfinalizowany z uwagi na jego stale rosnące koszty budowy zarówno bieżące, jak i prognozowane, co na pewnym etapie projektu może nie odpowiadać osobom odpowiedzialnym za finanse zamawiającego.