Zanim jednak powiemy sobie jak konkretnie mają brzmieć poszczególne postanowienia umowy odnoszące się do zdarzeń scrumowych, należy zadać sobie pytanie: czy opis tego obszaru w ogóle powinien znaleźć się w umowie?
Obserwując praktykę rynkową, można zauważyć co najmniej dwa modele będące odpowiedzią na tak postawione pytanie. Pierwszy z nich polega na całkowitym pominięciu w umowie postanowień odnoszących się do zdarzeń scrumowych. Model ten najczęściej ogranicza się do zawartego w umowie postanowienia odsyłającego do ogólnych zasad modelu Scrum. W opinii stron decydujących się na ten model, uzasadnieniem jego zastosowania jest oszczędność czasu i skrócenie przebiegu negocjacji, pozwalające na szybsze podpisanie przez strony umowy.
Znaczenie pojęcia „zgodnie z modelem Scrum” w umowie
Nie da się ukryć, że taki model istotnie przyspieszy proces negocjacyjny, pytanie tylko: czy warto to robić? Dobrze, jeżeli zawarte w umowie odesłanie kieruje nas do jakiegokolwiek opisanego zbioru zasad czy reguł odnoszących się do modelu Scrum (np. Scrum Guide). Dużo gorzej, jeżeli odesłanie ma charakter bardzo ogólny, ograniczający się w istocie do zdawkowego postanowienia typu „przebieg zdarzeń w ramach umowy będzie realizowany zgodnie z modelem Scrum”. W takim przypadku możemy być niemal pewni, że czas, jaki udało się nam zaoszczędzić podczas negocjacji, stracimy już na etapie realizacji umowy, próbując ustalić, co tak naprawdę rozumieliśmy pod pojęciem „zgodnie z modelem Scrum”.
Ponadto, pamiętajmy, że nawet odesłanie do konkretnego zbioru zasad i reguł scrumowych (np. Scrum Guide), nie gwarantuje stuprocentowej pewności, że strony tak samo rozumieć będą zawarte w nim postanowienia. Wynikać to może z odmiennych praktyk, doświadczeń i przyzwyczajeń w realizacji projektów scrumowych, które mogą się różnić w zależności od profilu branży lub podmiotu te zasady stosujące. Warto dodać, że właśnie Scrum Guide na swoich pierwszych stronach wskazuje, że poszczególne zasady stosowania Scruma mogą się różnić.
Najlepsze praktyki zapisów w umowach
Jaki z tego wniosek? Po pierwsze, nie ograniczajmy się w umowie do zdawkowych odesłań w rodzaju „zgodnie z modelem Scrum”. W najlepszym wypadku czas zaoszczędzony podczas negocjacji stracimy już na etapie realizacji projektu, poświęcając go na konieczne doprecyzowanie nazbyt ogólnie opisanych zasad. W najgorszym zaś wypadku, eskalacja konfliktu stron co do właściwego rozumienia opisu zdarzeń scrumowych doprowadzi do wstrzymania projektu, straty czasu, pieniędzy oraz nerwów.
Niekiedy następuje całkowite pominięcie w umowie postanowień odnoszących się do zdarzeń scrumowych. Model ten najczęściej ogranicza się do zawartego w umowie postanowienia odsyłającego do ogólnych zasad modelu Scrum. W opinii stron decydujących się na ten model, uzasadnieniem jego zastosowania jest oszczędność czasu i skrócenie przebiegu negocjacji, pozwalające na szybsze podpisanie przez strony umowy.
Po drugie, odsyłając w umowie do konkretnego zbioru zasad scrumowych, upewnijmy się, że zawarte w nim postanowienia nie pozostawiają zbyt dużej przestrzeni interpretacyjnej, ta bowiem może szybko spowodować konflikt stron co do właściwego rozumienia jego poszczególnych zapisów. Po trzecie, dążąc do uniknięcia wyżej sygnalizowanych ryzyk, poświęćmy w ramach negocjacji czas na wypracowanie przez strony załącznika do umowy, który w sposób precyzyjny i niepozostawiający przestrzeni na niepotrzebne wątpliwości określi rodzaj oraz przebieg zdarzeń scrumowych, jakie będą realizowane w ramach objętego umową projektu.
Opiszmy te obszary zdarzeń, które z punktu widzenia projektu są szczególnie ważne. Określmy maksymalny czas ich trwania, cel, lokalizację, członków zespołu scrumowego, którzy mają w nich uczestniczyć. Co ważne – tym razem bardziej z projektowego niż prawnego punktu widzenia – zasady te opiszmy właśnie w formie odrębnego załącznika do umowy. W ten sposób osoby realizujące projekt od strony operacyjnej, nie będą musiały za każdym razem przedzierać się przez postanowienia całej umowy, aby odnaleźć najczęściej, z ich punktu widzenia, potrzebne zapisy, odnoszące się do przebiegu realizacji projektu. Każda z osób, mająca doświadczenie w realizacji złożonych projektów informatycznych, wie, że ten prosty w swojej istocie zabieg może w sposób zasadniczy przyczynić się do wzrostu efektywności realizacji projektu.
Najważniejsze zdarzenie scrumowe
Sprint to z całą pewnością podstawowe zdarzenie w ramach Scruma. Z perspektywy postanowień umowy powinniśmy przede wszystkim pamiętać o uregulowaniu następujących obszarów z nim związanych. Są to:
1. Czas trwania sprintu – koniecznym postanowieniem jest określenie w umowie maksymalnego okresu trwania sprintu. Strony każdorazowo przed rozpoczęciem danego sprintu będą ustalać długość jego trwania, niemniej długość ta nie będzie mogła przekraczać ustalonej przez strony granicy maksymalnego czasu trwania sprintu. Zapis ten stanowi odzwierciedlenie jednej z naczelnych zasad Scruma, nakazującej, aby wszystkie zdarzenia miały wyraźnie określony, dopuszczalny, maksymalny czas ich trwania (time-boxed). Ma to na celu utrzymanie właściwej dyscypliny i dynamiki w ramach realizowanego projektu. Nie oznacza to oczywiście, że dane zdarzenie realizowane w ramach umowy nie może trwać krócej. Krócej może trwać zawsze. Ważne, aby nie trwało dłużej niż maksymalny czas przewidziany w umowie dla danej kategorii zdarzenia.
2. Zakres sprintu – kolejnym elementem dotyczącym sprintu, istotnym z punktu widzenia postanowień umowy, jest zapis, na podstawie którego strony zgodnie ustalają, że z chwilą dokonania przez strony ustaleń co do zakresu danego sprintu (Sprint Backlog), zakres ten ulega zamrożeniu. Tym samym do czasu zakończenia danego sprintu, żadna ze stron umowy nie może zmieniać zakresu prac przewidzianych do realizacji w danym sprincie. Innymi słowy, elastyczność co do wybranego obszaru projektu kończy się z chwilą jego ustalenia i przyjęcia do realizacji w ramach danego sprintu.
Istnienie dwóch niezależnych światów – świata umowy i świata projektu – to jedna z najczęstszych konsekwencji przeregulowania zapisów umowy i ujęcia ich w taki sposób, który istotnie odbiega od realiów realizacji projektu informatycznego. Zdrowy rozsądek i doświadczenie projektowe powinny podpowiadać nam, które z obszarów dotyczące zdarzeń scrumowych w danym projekcie powinny zostać uregulowane szczegółowo.
3. Przerwanie sprintu – kolejny obszar, który warto przewidzieć i uregulować w umowie to przerwanie sprintu. Modelowo takie uprawnienie powinno leżeć w gestii Product Ownera (zamawiającego), który w każdym czasie, albo w wyraźnie przewidzianych w umowie okolicznościach, może podjąć decyzję co do przerwania prac realizowanych w ramach konkretnego sprintu. Co istotne, jeżeli decydujemy się na przyznanie Product Ownerowi prawa do przerwania sprintu, pamiętajmy, aby jednocześnie, jednoznacznie uregulować związane z taką sytuacją okoliczności. Mamy tu w szczególności na myśli zasady rozliczeń co do przerwanych prac oraz transferu praw autorskich do tych elementów, które zostały wyprodukowane przez wykonawcę w ramach przerwanego sprintu.
4. Przestój sprintu – z punktu widzenia zamawiającego, warto przewidzieć w umowie prawo Product Ownera do zarządzenia przestoju pomiędzy zakończeniem jednego sprintu a rozpoczęciem kolejnego. Przy czym zapis ten nie powinien oczywiście ograniczać się do samego uprawnienia przyznanego w tym zakresie Product Ownerowi. Poza tym należy określić maksymalny czas takiego przestoju oraz warunki rozliczeń stron związanych z zatrzymaniem prac pomiędzy sprintami (opłata postojowa).
5. Inne zdarzenia – poza opisem zasad dotyczących przebiegu sprintu, warto również określić w umowie przynajmniej podstawowe reguły odnoszące się do pozostałych kategorii zdarzeń scrumowych. Tym samym opisując Dzienny Scrum, należy ustalić, jakie osoby z zespołu scrumowego mają w nim uczestniczyć, gdzie taki Dzienny Scrum będzie realizowany i oczywiście, jaki jest maksymalny, dopuszczalny czas jego trwania.
W istocie skład, lokalizacja oraz maksymalny czas trwania to te parametry, które powinny zostać określone w umowie dla każdej kategorii zdarzeń (Dzienny Scrum, Przegląd Sprintu, Retrospektywa). Ponadto, każdego z tych zdarzeń – ze względu na swój cel oraz specyfikę – mogą dotyczyć dodatkowe, szczególne regulacje przewidziane w umowie. I tak, opisując przebieg Retrospektywy Sprintu, warto wprowadzić zapis nakładający na strony umowy obowiązek implementacji do projektu wszelkich usprawnień będących rezultatem przeprowadzanych Retrospektyw. Tym samym jedna z naczelnych idei zwinnego zarządzania, kładąca nacisk na stały rozwój i doskonalenie działań w ramach projektu, znajdzie formalne umocowanie w ramach umowy.
Błąd przeregulowania
Opisując w umowie zasady przebiegu poszczególnych zdarzeń, warto zachować zdrowy umiar, aby nie popełnić błędu nadmiernego przeregulowania kontraktu. Zdarza się bowiem, że nadmierna inwencja autora umowy – zmierzająca do uregulowania możliwie największej liczby potencjalnie możliwych okoliczności – doprowadzi do powstania skostniałych procedur, które nie będą miały za wiele wspólnego z elastycznym (zwinnym) podejściem do realizacji projektu.
Nawet odesłanie do konkretnego zbioru zasad i reguł scrumowych (np. Scrum Guide), nie gwarantuje nam stuprocentowej pewności, że strony tak samo rozumieć będą zawarte w nim postanowienia. Wynikać to może z odmiennych praktyk, doświadczeń i przyzwyczajeń w realizacji projektów scrumowych, które mogą się różnić w zależności od profilu branży lub podmiotu stosującego te zasady.
Co więcej, efektem takiego podejścia może być bardzo niebezpieczna sytuacja, polegająca na istnieniu dwóch niezależnych światów: świata umowy i świata projektu. To bowiem jedna z najczęstszych konsekwencji przeregulowania zapisów umowy i ujęcia ich w taki sposób, który istotnie odbiega od realiów realizacji projektu informatycznego. Jednym słowem: zdrowy rozsądek i doświadczenie projektowe powinny podpowiadać nam, które z obszarów dotyczące zdarzeń scrumowych w danym projekcie powinny zostać uregulowane szczegółowo, a które z nich mogą zostać pozostawione do roboczych ustaleń wypracowanych wspólnie przez strony już na etapie realizacji projektu.
Łukasz Węgrzyn – prawnik w Kancelarii Radców Prawnych Maruta i Wspólnicy. Specjalista z zakresu prawa nowych technologii, własności intelektualnej i mediów. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora, MTV Networks oraz członek zespołu TMT kancelarii prawnej „Bird & Bird”. Tekst powstał przy współpracy z Marcinem Marutą – specjalista w zakresie projektów IT. Doradzał największym krajowym i międzynarodowym dostawcom usług IT oraz odbiorcom tych usług. Koordynuje obsługę prawną międzynarodowych sporów sądowych i arbitrażowych.
