Właściciel Produktu w pracach architektonicznych – czyli Scrum4EA (cz. II)

Analizując możliwość wykorzystania Scrum do budowy architektury korporacyjnej zacząłem zastanawiać się kto przy pracach architektonicznych powinien pełnić rolę Właściciela Produktu (Product Owner). Aby to wyjaśnić trzeba sięgnąć do odpowiedzialności przypisanych tej roli w Scrum. W tym celu wykorzystałem ponownie “The Scrum Guide”, w polskiej wersji językowej, opracowanej w ramach inicjatywy PodDrzewem.pl.Do najistotniejszych zagadnień związanych z tą rolą zaliczyłem:

• Właściciel Produktu to pojedyncza osoba, nie komitet.
• Właściciel Produktu reprezentuje interesy grupy interesariuszy (jest rzecznikiem “konsumentów” produktu dostarczanego przez Scrum), lecz osoby chcące zmienić priorytet elementu Rejestru Produktu, muszą przekonać do tego Właściciela.
• Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Wytwórczego.
• Właściciel Produktu jest jedyną osobą zarządzającą Rejestrem Produktu (Product Backlog), co obejmuje:
  • jasne artykułowanie elementów Rejestru Produktu,
  • określanie kolejności realizacji elementów Rejestru Produktu w sposób zapewniający osiąganie założonych celów,
  • zapewnianie wartości pracy wykonywanej przez Zespół Deweloperski,
  • zapewnianie, że Rejestr Produktu jest dostępny, przejrzysty oraz jasny dla wszystkich, a także, że dobrze opisuje to, czym Zespół Wytwórczy będzie się zajmował w dalszej kolejności,
  • zapewnianie, że Zespół Wytwórczy rozumie elementy Rejestru Produktu w wymaganym stopniu.

Zgodnie z TOGAF za prace architektoniczne odpowiada Rada Architektoniczna (Rada ds. Architektury Korporacyjnej), na czele której stoi Sponsor Prac Architektonicznych. Jest to ciało w skład którego powinny wchodzić osoby z poziomu C-level. W szczególności optymalnie byłoby, aby rolę Sponsora pełnił członek zarządu lub dyrektor generalny.

W takim kontekście patrząc na Właściciela Produktu można powiedzieć, że wykazuje on wiele podobieństw ze Sponsorem Prac Architektonicznych. Jedyną rzeczą, która jest niestosowalna w praktyce, to zarządzanie przez niego Rejestrem Produktu. Ciężko sobie bowiem wyobrazić sytuację, w której to członek zarządu dba, aby  np.  “Zespół Wytwórczy rozumiał elementy Rejestru Produktu w wymaganym stopniu”. Na szczęście w The Scrum Guide istnieje taki zapis: “Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny”. W takiej sytuacji możliwe jest delegowanie do Głównego Architekta (pełniącego rolę Scrum Mastera) zadań  z bieżącym zarządzaniem Rejestru Produktu. Co więcej w jednej z prezentacji poświęconych Scrum znalazłem zapis,  że Scrum Master “pomaga Właścicielowi Produktu w wyborze zaległości produktowych”.

Na koniec pojawia się jeszcze pytanie o Radę Architektoniczną. W TOGAFie jest to ciało obowiązkowe. W Scrum nie ma jej odpowiednika. Analizując pod tym kątem materiały w internecie znalazłem bardzo dużo opracowań nt. integracji Scrum z Prince2 (w którym jak wiadomo, takie ciało jak Rada Projektu występuje jako standard). Na tej podstawie nie widziałbym przeszkód, aby rozszerzyć trzy klasyczne role Scrum’a (tj. Właściciela Produktu, Scrum Mastera i Zespół Wytwórczy) o czwartą rolę – ” Product  Owner Board”, która miałaby głos doradczy dla Właściciela Produktu (szczególną rolę zwraca na to R. Pichler, w swojej książce “Agile Product Management with Scrum: Creating Products that Customers Love”, gdzie wskazuje on, że “The Product Owner Committee” = “death by committee”). W praktyce oznaczałoby to zmniejszenie jej odpowiedzialności w stosunku do “klasycznej” Rady Architektonicznej i wzmocnienie roli Sponsora Prac Architektonicznych.