Jak pisać umowy dla projektów IT realizowanych w modelu Agile? Cz. III.

,,U podstaw wszystkich problemów z projektami leży fakt, że ktoś komuś o czymś ważnym nie powiedział.”

Rozpoczynający artykuł cytatem z Kenta Becka, twórcy tzw. Programowania Ekstremalnego oraz współautora Manifestu Agile, w doskonały sposób podkreśla znaczenie współpracy zespołu, jako czynnika decydującego o sukcesie bądź porażce projektu. Dobrze napisana umowa, precyzująca między innymi zakres praw i obowiązków oraz odpowiedzialność poszczególnych ról projektowych w ramach Zespołu Scrumowego z pewnością ułatwi ich efektywną współpracę, tym samym zwiększając szanse na sukces projektu.

A jak to zrobić? Odpowiedzi na to pytanie chcielibyśmy poświęcić ten artykuł.

Zanim przejdziemy do opisywania postanowień umownych odnoszących się do konkretnych ról Zespołu Scrumowego, przyjrzyjmy się podstawowym zasadom, na których opiera się ich współpraca. Świadomość tych zasad jest warunkiem koniecznym dla prawidłowego opisania w umowie praw, obowiązków oraz zakresu odpowiedzialności. W wielu umowach „o dzieło” z którymi się spotykamy nacisk jest położony na odbiór i efekt prac, a nie na procedury ich realizacji – w Agilu trzeba zmienić takie myślenie. W tym zakresie umowa agile ma wiele cech umowy zlecenia, gdzie osobiste cechy świadczącego usługę są pierwszoplanowe.

„Osoby reprezentujące biznes muszą pracować razem z zespołem produkcyjnym – dzień w dzień – przez cały okres realizacji projektu.”

To pierwsza z zasad. Zawarta już w samym Manifeście Agile. Nie ukrywajmy, na pierwszy rzut oka wydaje się być mało odkrywczą konstatacją możliwą dla każdego w miarę logicznie myślącego osobnika, mającego jakiekolwiek doświadczenie w realizacji projektów, a już w szczególności projektów informatycznych.

W praktyce jednak to iście Kopernikańska Rewolucja, wywracająca do góry nogami zastany porządek rzeczy, w którym dotychczas plemię „Biznes” żyło doskonale odseparowane od plemienia „IT” i całego developmentu informatycznego, a ich ewentualna komunikacja była dla nich wzajemnie równie zrozumiała co język znaków dymnych plemienia Indian Lakota.

Ten tzw. syndrom plemion, opisany między innymi przez Carly Fiorinę w jej pamiętnikach z okresu kiedy przewodziła koncernowi Hewlett-Packard[1] niestety zdecydowanie zbyt często widoczny jest w umowach pisanych na potrzeby projektów informatycznych realizowanych w tradycyjnym modelu kaskadowym. Ze świecą szukać w tego typu umowach postanowień odnoszących się do współpracy konkretnych ról projektowych, a spotykana czasami w tych umowach klauzula odnoszącą się do tzw. teamelu Dedykowanego Dostawcy, nie stymuluje stron do wzajemnego współdziałania, ze względu na swój wybitnie jednostronny charakter. Agile, jak i odpowiadający mu model kontraktowy zrywa z syndromem plemion, stawiając na bliską i intensywną współpracę stron projektu.

Czy to jest proste? Nie. Przeciwnie, to jest trudne.

Potwierdza to choćby opinia twórców metody Scrum – Kena Schwabera i Jeffa Sutherlanda – którzy otwarcie przyznają że Scrum jest lekki, łatwy do zrozumienia ale … trudny do opanowania[2]. Sęk jednak w tym, że jest skuteczny. Inaczej mówiąc działa, pozwalając istotnie (naprawdę istotnie) zwiększyć szanse na powodzenie projektu.

Czy rzeczywistość to potwierdza?

Wystarczy przyjrzeć się wycenie rynkowej Apple Inc., firmie która w opinii ekspertów, nawet nie tyle wytwarza produkty w modelu Agile, ale jest Agile sama w sobie. Małe zespoły projektowe (dwóch (!) inżynierów było odpowiedzialnych za przekonwertowanie kodu wyszukiwarki Safari na iPada), genialny Product Owner (o nim więcej za chwilę), praca w krótkich cyklach iteracyjnych oraz legendarny już dla Apple model odpowiedzialności indywidualnych członków zespołu zawierający się w akronimie DIR (z ang. Directly Responsible Individual), to tylko niektóre z cech tej organizacji świadczące o zaawansowanym rozumieniu i stosowaniu modelu Agile w codziennym cyklu biznesowym.

Oczywiście Apple nie jest jedyną ani tym bardziej pierwszą organizacją, która zrozumiała, że ścisła współpraca „Biznesu” z „IT” jest czynnikiem krytycznym dla powodzenia projektu. Już w latach 40-tych ubiegłego stulecia, Richard Feynman, członek zespołu projektu Manhattan, odpowiedzialnego za stworzenie amerykańskiej bomby jądrowej oraz późniejszy laureat Nagrody Nobla w dziedzinie fizyki, zauważył, że odseparowanie poziomu strategicznego (Biznes) od poziomu taktyczno – operacyjnego (IT) w sposób istotny wpływa na efektywność prac realizowanych w ramach projektu.

W rezultacie stosowania takiego modelu, zespół taktyczno – operacyjny wie tylko „co” ma zrobić, natomiast nie wie „dlaczego”. A to właśnie, jak podkreśla Feynman, wiedza na temat „dlaczego” coś ma zostać zrobione jest zapalnikiem innowacyjnego podejścia do pracy operacyjnej, który nomen-omen pozwala na uwolnienie energii zespołu developerskiego, a tym samym osiągnięcie sukcesu całego projektu.

Jak to się ma do umowy?

Umowa dla projektów realizowanych w metodzie Scrum musi w sposób możliwie precyzyjny a zarazem przejrzysty określać role projektowe, zakres ich praw i obowiązków oraz odpowiedzialności za wybrane obszary projektu.

Postanowienia te nie mogą sprowadzać się do nieostrych sformułowań typu „koordynator projektu odpowiedzialny jest za właściwą koordynację działań operacyjnych w ramach projektu, a działania te będzie podejmował ze starannością należytą, odpowiadającą najwyższym międzynarodowym standardom rynkowym”.

Postanowienia te muszą precyzyjnie lokalizować zakres czynności poszczególnych ról Zespołu Scrumowego (Product Owner, Scrum Master, Zespół Developerski) wraz z odpowiadającą tym czynnościom decyzyjnością oraz odpowiedzialnością poszczególnych aktorów projektu scrumowego.

To właśnie dzięki przejrzystej matrycy decyzyjności i odpowiedzialności poszczególnych ról projektowych jesteśmy w stanie znacząco zwiększyć efektywność współpracy w ramach projektu, ograniczyć ryzyka związane z obszarem tzw. „ziemi niczyjej”, tym samym podwyższając szanse finalnego sukcesu przedsięwzięcia.

„Najbardziej skutecznym i wydajnym sposobem przekazywania informacji do i w ramach zespołu projektowego jest bezpośrednia rozmowa.”

Ot co, chciałoby się powiedzieć kolejna zdrowo rozsądkowa mądrość. Cały problem w tym, że jej stosowanie w praktyce w 9 na 10 przypadków napotyka na wysoki i gruby mur utkany z korporacyjno – waterfollowskich przyzwyczajeń, gdzie znakomita większość komunikacji przesyłana jest mailem (zgodnie z badaniami uznawanym za najgorszy sposób komunikacji w ramach zespołu[3]) i to najczęściej wtedy kiedy osoba kierująca projektem ze strony zamawiającego ma na to czas, pomiędzy „n” innych rzeczy, jakie ma do zrobienia poza samym projektem.

Bo cóż innego z tej zasady wynika jak między innymi nie to, że „Biznes” musi być fizycznie obecny na spotkaniach z „IT”. Musi być dla inżynierów realnie dostępny, dyspozycyjny, responsywny, i co gorsza (!) decyzyjny. I nie chodzi tu o cotygodniowe spotkania statusowe. Chodzi o dostępność codzienną (dzień po dniu), a jeśli już nie zawsze fizyczną (bądźmy realistami) to zdalną, pozwalającą w sposób szybki podejmować decyzje co do kierunku projektu, produktu, jego pożądanych funkcjonalnościach, parametrach, etc.

Tylko taki model działania zapewni odpowiednią dynamikę projektu, kluczową dla szans powodzenia całego przedsięwzięcia.

Co zatem wpisujemy do umowy?

Nakładamy na poszczególnych aktorów projektu żelazne zobowiązania co do fizycznej obecności na wybranych kategoriach spotkań scrumowych, pełnej dyspozycyjności oraz responsywności gwarantujących utrzymanie właściwej dynamiki projektu.

Odpierając zarzuty tradycjonalistów, szermujących hasłami, „że nasz Biznes na coś takiego na pewno się nie zgodzi, bo ma 100 innych rzeczy na głowie”, posłusznie acz stanowczo odpowiadamy – jeśli się nie zgodzi, to niech zapomni o zwinnym podejściu do realizacji projektów. Odsyłamy niniejszym już do wyżej przywołanej tezy twórców Scruma – Scrum jest trudny, czasami bardzo trudny do adaptacji. W pewnych obszarach wymaga on wręcz całkowitego zredefiniowania dotychczasowego podejścia do realizacji projektów.

Zatem albo umawiamy się na zwinny projekt i piszemy na jego potrzeby odpowiednią umowę, albo pozostajemy przy tradycyjnej metodzie projektowej, akceptując wszelkie wynikające z takiego rozwiązania konsekwencje.

A jak już jesteśmy przy odpieraniu zarzutów, to warto przy tej okazji rozprawić się z mitem braku dyscypliny w projektach zwinnych. Mitem, który rozpływa się nad modelem Agile, powodując powszechne wrażenie, jakoby w modelach zwinnych wszystko jest nieznane, a my po prostu tworzymy w atmosferze wzajemnej miłości, wolności i zaufania licząc, że na końcu coś z tego pewnie nam wyjdzie, a jak nie wyjdzie to… trudno. Nic bardziej mylnego.

Agile, w tym metoda Scrum, to jedna z najbardziej ekstremalnie zdyscyplinowanych metod realizacji projektów, gdzie każdy z członków zespołu projektowego ma precyzyjnie określony zakres działań i odpowiedzialności, a wszelkie tzw. Zdarzenia (Sprinty, Retrospekcje, Planowania, Dzienny Scrum) są w umowie na sztywno czasowo ograniczone (z ang. time-boxed), a od tej zasady nie ma żadnych wyjątków. Choć nie da się ukryć, że zaszyta w modelach Agile elastyczność zmiany przedmiotu umowy jest prawnie najtrudniejsza do opisania i kontroli podczas realizacji.

Product Owner

Jedna z trzech zasadniczych ról w ramach Zespołu Scrumowego. W praktyce to głos zamawiającego lub w istocie sam zamawiający. To on decyduje czy i na jakim etapie produkt zostanie wydany, podejmuje decyzje co do kontynuacji samego projektu, ma ostateczny głos w kwestii priorytetyzacji poszczególnych elementów zawartych w Rejestrze Wymagań i – last, but not least – jest odpowiedzialny za komunikację na linii Business – IT.

Podsumowując Product Owner to rola zamawiającego, którą cechują dwa zasadnicze parametry:

  • decyzyjność,
  • dyspozycyjność.

Decyzyjność

Umowa powinna zawierać wyraźne umocowanie (pełnomocnictwo) udzielane Product Ownerowi przez zamawiającego do podejmowania decyzji potrzebnych dla efektywnej realizacji projektu. Pisząc umowę zwracać należy szczególną uwagę na zakres pełnomocnictwa udzielanego Product Ownerowi. Niewystarczający lub zdawkowo opisany zakres upoważnienia Product Ownera, uniemożliwiający mu podejmowanie szybkich decyzji w ramach projektu może w łatwy sposób sparaliżować cały projekt i wymusić konieczność każdorazowego zatwierdzania przez zwierzchników Product Ownera podejmowanych przez niego decyzji. To zaś w oczywisty sposób rozbija dynamikę projektu i znacząco utrudnia jego sukces. Zatem na samym początku – prawidłowo tj. odpowiednio szeroko – umocujmy w umowie Product Ownera do wykonywania swojej roli.

Dyspozycyjność

To już dużo trudniejsza historia z przyczyn przywołanych już powyżej w artykule. Umowa powinna zawierać wyraźne zobowiązanie fizycznej obecności Product Ownera na wybranych kategoriach zdarzeń scrumowych.

O jakich zdarzeniach tu mowa?

Co najmniej o Planowaniu Sprintu i Przeglądzie Sprintu. Co do reszty Zdarzeń pozostawiamy to już do indywidualnej decyzji stron. Jednocześnie nie ukrywając, że im obecność Product Ownera będzie częstsza na spotkaniach z Zespołem Deweloperskim tym lepiej dla powodzenia projektu.

Celowym jest również zakreślenie w umowie przestrzeni czasowej, na czas której zamawiający zagwarantuje pełną dyspozycyjność Product Ownera dla projektu, o który się umawiamy. Dodatkowo zamawiający powinien oświadczyć, że zapewnia priorytet działaniom podejmowanym przez Product Ownera na potrzeby projektu, względem pozostałych, poza projektowych aktywności, do jakich osoba pełniąca rolę Product Ownera jest zobowiązana wobec zamawiającego.

Warto również pamiętać o obowiązku należytej responsywności Product Ownera. To cecha kluczowa, szczególnie biorąc pod uwagę dynamikę oraz dyscyplinę czasową jaka towarzyszy zwinnie realizowanym projektom. W wersji soft te postanowieniasprowadzą się do obowiązku responsywności tak szybko jak to tylko możliwe, w wersji hard zostaną sparametryzowane, poprzez określenie przedziału czasowego w jakim Product Owner zobowiązany jest do reakcji.

Z punktu widzenia wykonawcy warto wprowadzić do umowy klauzulę gwarantującą odpowiednie kompetencje i doświadczenie Product Ownera, referującą najczęściej do załącznika będącego portfolio projektów zwinnych jakie nasz Product Owner już zrealizował. Jeśli zatem uzyskamy już pewność, że Product Owner jest wystarczająco kompetentny i doświadczony dla potrzeb naszego projektu, wprowadźmy do umowy postanowienia uniemożliwiające łatwą zmianę Product Ownera, ograniczające taką możliwość tylko do okoliczności od zamawiającego obiektywnie niezależnych jak choroba, śmierć czy złożenie wypowiedzenia.

Poza powyższymi postanowieniami umowa powinna zawierać przejrzysty katalog czynności zarezerwowanych dla niezależnej decyzji Product Ownera. Taki krok pozwoli w dużym stopniu ograniczyć ryzyko niepotrzebnego sporu co do obszaru tzw. ziemi niczyjej.

O jakich tu mowa czynnościach?

Jak na prawników przystało odpowiemy – zależy. Między innymi od tego jak szerokie pełnomocnictwa Product Owner posiada.

Warto jednak pamiętać o pewnym minimalnym standardzie, poniżej którego pozycja Product Ownera nie powinna być ograniczana, a który sprowadza się m.in. do działań związanych z zarządzaniem Rejestrem Wymagań, jego priorytetyzacją, aktualizacją, jak również decyzjami w przedmiocie kontynuacji projektu.

Nie ma się co oszukiwać, te postanowienia nie będą wybitnie łatwe do wynegocjowania. W szczególności w polskich realiach rynkowych de facto często dopiero rozpoczynających swoją przygodę z modelem Agile. To oczywiste, że wszystko dzieje się łatwiej kiedy Product Owner jest postacią formatu Steve’a Jobs’a, Jeff’a Bezos’a czy Elon’a Musk’a osadzonych na najwyższym piętrze firmowej drabiny, w pełni decyzyjnych i w dosłownie obsesyjny sposób oddanych projektowi, gotowi poświęcić każdą minutę na pracę z zespołem deweloperskim, aby możliwie szybko dojść do upragnionego celu. Nie mniej właściwe nastawienie do współdziałania, odpowiednie kompetencje ról projektowych i dobrze napisana umowa są w stanie każdego z nas w sposób istotny przybliżyć do pomyślnej realizacji zwinnego projektu.

W osobnym wątku poruszymy zagadnienie konsekwencji, kiedy Product Owner nie współdziała – niestety mogą one być bardzo bolesne dla zamawiającego i ich opis jest kluczowy dla umowy.

Scrum Master

To kolejna z ról projektowych Zespołu Scrumowego. W Zespole Scrumowym rolę Scrum Mastera chyba najlepiej oddaje określenie coach lub mentor.

Scrum Master prowadzi permanentny coaching Zespołu Deweloperskiego, dbając jednocześnie o jego dobrą atmosferę i o to, aby cały proces projektowy prowadzony był zgodnie z zasadami modelu Scrum, dodatkowo motywując i stymulując Zespół Deweloperski do lepszej, efektywnej i bardziej wydajnej pracy.

Nie powtarzając się niepotrzebnie chcemy tylko zasygnalizować, że umowne postanowienia jakie komentowaliśmy powyżej w odniesieniu do roli Product Ownera, znajdują w pewnym zakresie swoje odpowiednie zastosowanie do funkcji Scrum Mastera. Mamy tu na myśli w szczególności wymóg fizycznej obecności na określonych kategoriach Zdarzeń scrumowych, responsywności czy dyspozycyjności dla pozostałych członków Zespołu Scrumowego. To samo dotyczy klauzul umownych regulujących zakaz zmiany Scrum Mastera bez ważnych powodów oraz oświadczeń, w których strona projektu zapewniająca Scrum Mastera gwarantuje jego należyte kompetencje i doświadczenie, potwierdzone odpowiednio grubym portfolio zrealizowanych już zwinnych przedsięwzięć.

Z punktu widzenia zamawiającego chcemy zwrócić szczególną uwagę na ten ostatni aspekt, a mianowicie wpisanie do umowy wyraźnego uprawnienia zamawiającego umożliwiającego mu weryfikację deklarowanych kompetencji i doświadczenia Scrum Mastera. Innym modelem pozwalającym ograniczyć ryzyko związane z nietrafionym Scrum Masterem jest wpisanie w umowie krótkiej procedury pozwalającej na dokonanie przez strony wspólnego wyboru kandydata na pozycję Scrum Mastera. Strony, w oparciu o ustalone kryteria, będące z punktu widzenia charakteru projektu cechami szczególnie pożądanymi, razem dokonują wyboru kandydata do roli Scrum Mastera.

Pamiętajmy, że Scrum Master to rola mająca m.in. czuwać nad tym, że projekt jest realizowany zgodnie z właściwymi zasadami metody Scrum. To rola szczególnie odpowiedzialna, zwłaszcza wtedy kiedy tak zamawiający jak i dostawca nie posiadają jeszcze doświadczenia pozwalającego w porę zauważyć i zapobiec takiej sytuacji. Proponowane powyżej mechanizmy umowy umożliwiające uprzednią weryfikację kompetencji i doświadczeń Scrum Mastera lub pozwalające na jego świadomy i przemyślany wybór w dużej mierze pozwalają ograniczyć ryzyko związane z nietrafionym wyborem kandydata do tej roli.

Na zakończenie tej części warto podkreślić, że zdarzają się projekty, a w konsekwencji pisane na ich potrzeby kontrakty, które w ogóle nie przewidują roli Scrum Mastera. Nie mniej winni jesteśmy wyjaśnienie, że takie projekty realizowane są najczęściej przez organizacje posiadające już duże doświadczenie w modelach zwinnych.

Zespół Deweloperski

„Różnica pomiędzy najlepszym a dobrym pracownikiem zajmującym się sprzętem komputerowym może wynosić 2:1, jeśli masz szczęście. W branży samochodowej, może 2:1. W branży programistycznej co najmniej 25:1. Różnica pomiędzy świetnym a dobrym programistą jest właśnie taka.”

W ten sposób Steve Jobs z właściwym sobie urokiem podkreślił znaczenie jakie dla powodzenia projektu mają kompetencje biorących w nim udział programistów. Nie sposób się z tym nie zgodzić! Właśnie dlatego w Scrumie to Zespół Deweloperski odgrywa jedną z kluczowych ról projektowych, która powinna znaleźć potwierdzenie w postanowieniach umowy.

Z perspektywy zamawiającego u mowie należy zawrzeć postanowienia gwarantujące odpowiednio wysokie kompetencje i doświadczenie poszczególnych członków Zespołu Deweloperskiego.

Zespół Developerski powinien spełniać dwa kluczowe parametry:

  • interdyscyplinarność (samowystarczalność) tj. zespół posiada kompletny zestaw kompetencji pozwalający na realizację projektu, bez konieczności korzystania z zasobów zewnętrznych,
  • międzyfunkcjonalność tj. członkowie Zespołu Developerskiego posiadają kompetencje pozwalające im się wzajemnie zastępować.

Kontrola nad zespołem pojawia się prawie w każdej umowie, ale klauzule w umowach agile są o wiele bardziej rozbudowane. Np. jedna z nich może wymagać od dostawcy zespołu który razem pracuje od dłuższego czasu – weryfikacja c.v. konsultantów jest o wiele bardziej staranna niż w większości typowych umów o dzieło.

Dodatkowo umowa powinna nakładać ograniczenia co do liczebności Zespołu Deweloperskiego oraz jego lokalizacji. Co do lokalizacji, umowa powinna jasno określać miejsce, w którym członkowie Zespołu Deweloperskiego będą wykonywali prace na potrzeby projektu. Przez miejsce należy rozumieć jedną, fizycznie istniejąca lokalizację gwarantującą wszystkim członkom Zespołu optymalne warunki realizacji pracy projektowej, w tym komunikacji z pozostałymi rolami scrumowymi. Jeśli ma ją zapewnić zamawiający, to także dokładnie to opiszmy, także z parametrami zapewnianej łączności.

Podobnie jak miało to już miejsce w przypadku Product Ownera i Scrum Mastera umowa powinna przewidywać określone mechanizmy uniemożliwiające wykonawcy dowolną zmianę członków Zespołu Deweloperskiego. Zmiany te powinny zachodzić wyłącznie w wyjątkowych okolicznościach. Tutaj może się sprawdzić autorski mechanizm kar umownych.

Kolejny ważny element, to zapewnienie w umowie pełnej niezależności Zespołu Scrumowego w czasie realizacji prac projektowych podczas Sprintu. Nikt, nawet Scrum Master nie ma prawa mówić Zespołowi Developerskiemu co należy zrobić w celu osiągnięcia zakładanego celu Sprintu. Zespół Developerski jest w tym zakresie całkowicie niezależny i tylko on ponosi z tego tytułu odpowiedzialność.

Na zakończenie warto dodać, że w zaawansowanych projektach zwinnych zdarza się że Zespół Developerski złożony jest tak z teamelu zamawiającego jak i wykonawcy. To oczywiście świat idealny Scruma, pozwalający najpełniej wykorzystać jego potencjał. Z prawnego punktu widzenia, w przypadku sporu może jednak wystąpić trudność co do właściwego ustalenia odpowiedzialności tj. ustalenia konkretnie kto i za co jest odpowiedzialny. Dlatego też, o ile strony nie posiadają sporego doświadczenia w realizacji projektów zwinnych, nie rekomendujemy takiego rozwiązania.

Podsumowując, w niniejszym artykule staraliśmy się zwrócić uwagę na szczególnie istotny obszar projektów zwinnych dotyczący występujących w nich ról projektowych. Przedstawione przez nas rozwiązania mają charakter modelowy i mogą być poddawane odpowiednim modyfikacjom w zależności od potrzeb konkretnego projektu. Nie mniej to, na czym zależało nam szczególnie to zwrócenie Państwa uwagi na precyzyjne i przejrzyste ujęcie w umowie praw, obowiązków oraz odpowiedzialności poszczególnych ról projektowych charakterystycznych dla modeli zwinnych. Jak ująć w umowie poszczególne Zdarzenia takich modeli postaramy się opowiedzieć już w następnym artykule.

[1] Fiorina Carly „Nie żałuję niczego”; Wydawnictwo: Difin; tłumaczenie: Krzysztof Rastawicki.
[2] Ken Schwaber, Jeff Sutherland „Scrum Guide”.
[3] Alex Sandy Petland; “The New Science of Building Great Teams”; Harvard Business Review 4/2012.


Zobacz kolejne artykuły z tej serii