Czy RODO powinno być implementowane przy użyciu Scrum? Skoro mamy Agile, to chyba tak.Rodeo z RODO trwa w najlepsze. Jedni są już w środku całego zamieszania biegnąc przed siebie jak bezgłowe kury nie czekając na ustawę. Inni dopiero się budzą, bo to na maj ma być, a zanim zaczną sprawdzać to wiesz … Tak czy inaczej obserwuję jak kolejne organizacje zjadają swój ogon przy okazji implementacji RODO. Jednocześnie tworzą problemy i zajmują się ich rozwiązywaniem. Poobserwowałem kilka organizacji, stoczyłem kilka dyskusji przy okazji prezentacji, szkoleń i spotkań. Rozmawialiśmy nawet o kwestii RODO i innych inicjatywach regulacyjnych na Agile Coach Camp w zeszłym roku. Czas na krótkie podsumowanie i wyciągnięcie kilku wniosków w kontekście Scrum. Rozpatrzymy kilka przypadków, ponieważ RODO może być implementowane w rozwijanych produktach albo produktach utrzymywanych. 

Czym jest RODO?

Europejska regulacja General Data Protection Regulation w Polsce przyjęła nazwę Rozporządzenie Ogólne o Ochronie Danych Osobowych. RODO jest rozporządzeniem unijnym, do którego mamy obowiązek dostosować się do 25 maja 2018. Rozporządzenie dotyczy zbierania, przechowywania i wykorzystywania danych osobowych. Oprócz wzmocnienia i uporządkowania ochrony danych, na straży której dotychczas stało GIODO pojawiły się pewne nowości. Użytkownicy mają prawo do wglądu do zgromadzonych danych, mogą poprosić o przeniesienie lub usunięcie danych.

Czym jest RODO z punktu widzenia Scrum? RODO na pewno nie jest produktem z punktu widzenia klienta. Nie przynosi też wartości z punktu widzenia firmy. Implementacja RODO ogranicza ryzyko otrzymania kary. Jeśli nie produkt to znaczy, że są to zmiany dotyczące wszystkich produktów. RODO reprezentuje zestaw wymagań niefunkcjonalnych, które musimy zaimplementować.

Produkty, których dotyczy RODO są rozwijane w Scrum

Skoro już budujemy w Scrum, to sprawa wydaje się banalnie prosta. Będziemy implementować RODO w ramach budowania produktu w Scrum.

Do Product Backlog każdego Produktu powinny trafić elementy dotyczące RODO. I co dalej będzie się z nimi działo? Product Owner dla każdego produktu powinien określić kolejność. Jednak jest tutaj kilka problemów do rozwiązania. Pierwszy to problem interpretacji i implementacji RODO. Jest ryzyko, że każdy Product Owner zrozumie wymagania ustawy inaczej. Dodatkowo każdy Zespół Deweloperski może te wymagania na swój sposób zaimplementować. Może powstać kilka konkurencyjnych rozwiązań niespójnych pomiędzy systemami. Może zatem warto by było mieć jedną osobę odpowidzialną za intepretację wymagąń wynikajacych z ustawy i spójną implementację we wszystkich produktach. Taki Product Owner od RODO będzie w sumie interesariuszem dla innych Product Ownerów.

Druga kwestia jest taka, że kiedy Product Owner będzie porównywać wartość elementów PBI dotyczących RODO z innymi, to w większość i przypadków RODO przegra, Oznacza to, żre PBI z RODO będą nisko na Product Backlog, Tym samym mogą zostać późno zaimplentowane, Za późno, a mamy jednaj twardą datę. Potrzebujemy mechanizmy wymuszające wysokie miejsce na liście w Product Backlog przynajmniej poziom wyżej niż Product Owner. Może compliance ma odpowiednią siłę przebicia?

RODO jako osobny projekt ze Scrum

A co jeśli trzeba zaimplementować RODO w utrzymywanych produktach, które obecnie nie są rozwijane? Wówczas trzeba powołać tymczasową organizację do wprowadzenia potrzebnych zmian, czyli po prostu projekt. A czy użycie Scrum w ramach takiego projektu ma sens? Spójrzmy jakie kryteria należy spełnić.

Czy wymagania są niejasne, a część z nich powstanie w trakcie wykonywania pracy? Zdecydowanie tak. Czy technologia jest mało przewidywalna? Odnajdywanie odpowiednich miejsc w kodzie i praca ze starym kodem powodują, że przewidywalność będzie niska. Czyli patrząc na Stacey graph wyszłoby nam, że ten rodzaj pracy doskonale nadaje się do zastosowania Scrum. W dodatku pracę możemy zaplanować i dostarczać przyrostowo oraz iteracyjnie. Wszystko wydaje się przemawiać na korzyść Scrum.

RODO to nie Must, wszystkie wymagania to nie jest Must, zaimplementowanie RODO jest must, ale sposób wykonania tego może być bardzo różny, od minimalnego MVP po gold-plating. Trzeba rozdrobnić i podejść tak samo jak do backlogu produktu.
Może Good Enough wystarczy. Z punktu widzenia RODO trzeba iść przekrojowo i zapewnić spełnienie RODO w minimalnym stopniu w każdym obszarze.

Spójrzmy jednak na całą sytuację z punktu widzenia samego procesu Scrum. Czy budujemy produkt? RODO najczęsciej dotyczy systemów, platform a nie produktów. Implementacja RODO w ramach osobnego projektu będzie oznaczała konieczność zbudowania zespołu z ludzi o różnych kompetencjach i wiedzy domenowej. Prawdopodobnie członkowie Zespołu Developerskiego będą pracowali na zupełnie innych systemach. Będziemy mieli z zespole różne technologie: Java, .Net, SQL, Python, COBOL. Być może będziemy mieli też mix dostawców.

Zastanówmy się jak będzie wyglądało Planowanie Sprintu, jaki będzie Cel Sprintu i jak będzie przebiegało Daily Scrum. Planowanie skupi się bardziej na indywidualnej zajętości członków zespołu (capacity allocation). Celem Sprintu będzie coś w rodzaju: Zaimplementujmy więcej RODO. Daily Scrum będzie raczej nudne, bo większość osób nie będzie interesowało co kolejna osoba mówi i nie będą w stanie zaplanować kolejnego dnia pracy. Spójrzmy oczami wyobraźni na Sprint Review. Trudno oczekiwać, że zobaczymy jeden, zintegrowany przyrost produktu. Zespół będzie przełączał się pomiędzy różnymi systemami, a każdy interesariusz będzie chciał zobaczyć tylko to co jego dotyczy. O ile oczywiście interesariuszy z biznesu będzie interesowało jak RODO zostało spełnione w ich produktach.

Planowanie i szacowanie też będą bardzo trudne z uwagi na specyfikę pracy. Podobnie jak w przypadku naprawiania defektów, Developer musi znaleźć miejsce, gdzie należy wprowadzić zmianę. Analiza i szukanie odpowiedniego miejsca są trudne do oszacowania. A jak już wiemy gdzie i co zrobić, to zwykle zrobienie tego zajmuje już bardzo mało czasu i warto zrobić to od razu.

No ale powiedzmy, że zwinna praca z zakresem i przyrostowe dostarczanie zmian nadal jest dla nas atrakcyjne. Z powyższej analizy wychodzi, że Scrum się nie nadaje do tego typu pracy. A czy jest coś innego? Oczywiście że tak, jest jeszcze Kanban. Zidentyfikowane wymagania albo nawet zadania trafiają do backlogu, który jest kolejką dla Zespołu Developerskiego. Kiedy Developer ma wolne moce przerobowe bierze kolejną kartkę z obszaru, który go dotyczy, robi analizę, projektu rozwiązanie i implementuje je. Potem bierze kolejne zadanie. Mamy Daily Status do zgłaszania problemów, które napotykamy. Co pewien czas możemy z robić wdrożenie gotowych poprawek na produkcję lub wdrażać je na bierząco w ramach ciągłej integracji.

Tak, kanban lepiej tutaj pasuje.

Podsumowanie

Słuchając plotek i patrząc na to co rząd robi można spodziewać się że co roku będzie coś podobnego jak RODO (wcześniej było JPK). Warto wypracować sobie pewien sposób reagowania. Czym innym jest implementacja w rozwijanych produktach, a czym innym jest poprawianie wdrożonych systemów.
Nowe produkty czy projekty też powinny uwzględnić wymagania RODO i przestać tworzyć dług dla spłacenia dla specjalnego zespołu od RODO. Ten zespół nigdy nie nadąży. RODO nie będzie spełnione, więc ryzyko dla organizacji jest takie samo.