Role w modelu Spotify vs Less - bryk :)

Role w modelu Spotify vs Less - bryk :)

Product Owner, Scrum Master, Development Team (Zespół Wytwórczy). 3 proste role, a tyle zamieszania wokół. 

No tak, “bo u nas w organizacji są jeszcze: Project Manager, Product Manager, IT Manager, Delivery Manager, Line Manager, Architect, Senior Developer, Junior Developer, Release Manager, QA Lead, ….” 

Spróbujmy w takim razie przyjrzeć się, jak to wygląda, wg. dwóch popularnych przepisów (Spotify, oraz LeSS).

***

Scrum Guide w podstawowej wersji wspomina faktycznie tylko jeden zespół, który posiada komplet kompetencji do wytworzenia wartościowego przyrostu. Jest tu kilka cichych założeń – po pierwsze, członkowie faktycznie są Scrum Developerami z krwi i kości – (“eXtreme Programmers“), a także wytwarzają w otoczeniu pozbawionym zależności. Sytuacja dość idylliczna sama w sobie. Do tego, częstą przyczyną powstawania firm jest założenie, że w kilka osób, uda się wytworzyć coś, czego pojedyncza osoba nie jest w stanie – a idąc dalej tym tropem, zakłada się, że kilkadziesiąt osób będzie prosperowało lepiej, niż np. max 9 😉

Faktycznie organizacje rosną, bo jest popyt na ich usługi/produkty – z drugiej strony chciałyby zachować zwinność (takie, które zaczynały organicznie od jednego zwinnego zespołu), lub dopiero zwinność nabyć, będąc już wielkimi firmami, często złożonymi z silosowych departamentów poszczególnych kompetencji/warstw.

To jest moment, w którym pojawia się czas na skalowanie organizacji. Mimo, iż wcale nie uważam, żeby temat ról był tutaj najważniejszy, klienci często od tego właśnie zaczynają. Pewnie dlatego, że to (czyt: “stołki”) budzi dużo emocji, a także czują, że trudno zmienić procesy, minimalizować zmiany kontekstów pracowników, upraszczać linie raportowania, jeśli nie zmieni się struktura organizacyjna.

Bardzo popularnym w ostatnich latach modelem skalowania stał się tzw. “model Spotify”, czyli tribes, chapters, etc. Postanowiłem opisać w kilku zdaniach role w nim występujące, a przy okazji zestawić go z rolami w LeSS (Large Scale Scrum). Niech to będzie taki “bryk” dla wszystkich, którzy nie mają czasu przeczytać pełnej lektury, albo obejrzeć ekranizacji 😉

Spotify

 

Squad – międzyfunkcjonalny zespół (ang. cross-functional) – kolokowany, posiadający wszystkie niezbędne kompetencje by zaprojektować przyrost, zaimplementować, przetestować i wydać na produkcję. Może pracować w Scrum lub Kanban. Jest to pewnego rodzaju mini-startup, posiadający długoterminową misję i odpowiedzialność za konkretny produkt/komponent.

Squad nie ma formalnego leadera, natomiast ma przypisanego Product Ownera, który raportuje do Tribe Leadera. Nie występuje tutaj Scrum Master, bo squad ma być jak najbardziej samoorganizujący się – posiada dostęp do Agile Coacha, który w początkowej fazie pomaga ustawić rytm ceremonii i facylitację (planowanie, review, retrospekcje, refinement backlogu), prowadzi 1-on-1 coaching.

Tribe – mini firma, pewnego rodzaju inkubator squadów, zorganizowany wokół konkretnego obszaru biznesowego. Tribe Leader zapewnia najlepsze środowisko rozwoju dla wszystkich składów. Odpowiada również za business case realizowanych inicjatyw, oraz ich nadrzędny priorytet w ramach tribe. Tribe powinien liczyć nie więcej niż 100 osób – powyżej tej liczby utrudniony jest bezpośredni kontakt, tworzy się niepotrzebna biurokracja i polityka. Raz na jakiś czas (np. kwartalnie) tribe organizuje spotkanie wszystkich squadów podczas którego prezentowane są najciekawsze funkcjonalności w formie demo, nowe narzędzia. W praktyce bardzo lubiane są również dni hackowania – tzw. hackatony.

Chapter – autonomia squadów i tribe’ów mogłaby sprawić, że np. tester ze squadu A próbuje rozwiązać problem, który tester ze squadu B rozwiązał już jakiś czas temu. Aby uzyskać spójność kompetencji i wiedzy, dostęp do nowych narzędzi i know-how, wprowadzono chaptery, czyli liniową strukturę skupiającą specjalistów danych kompetencji (np. programiści, testerzy, analitycy). Chapter organizuje regularne spotkania (np. raz w tygodniu), aby omówić ważne merytoryczne kwestie, wymienić się doświadczeniami z poszczególnych squadów.

Chapter Leader jest kierownikiem liniowym członków „chapteru” (na marginesie – najlepsze polskie tłumaczenie to chyba: sekcja), ze wszystkimi tradycyjnymi obowiązkami, takimi jak rozwijanie ludzi, ustalanie wynagrodzeń itp. Jednak chapter leader jest także częścią squadu i jest zaangażowany w codzienną pracę, która pomaga mu pozostać w kontakcie z rzeczywistością.

Gildie – bardziej organiczna (oddolnie powoływana) grupa zainteresowań (tzw. Community of Practice). Często zrzesza osoby ze wszystkich chapterów danego tematu, ale uczestniczyć może ktokolwiek zainteresowany. Przykład: Gildia Frontend, Gildia Mobile, Gildia Software Craftsmanship, Gildia Agile

Różnice względem tradycyjnej struktury macierzowej:

  • Zwykle osoby o określonych kompetencjach umieszczane są w departamentach/zespołach funkcyjnych, siedzą razem, następnie przydziela się im zadania projektowe. W modelu Spotify, każda osoba fizycznie przebywa ze swoim squadem i jest skupiona na misji i odpowiedzialności squadu, jako główny przedmiot jej działań. O priorytetach decyduje Product Owner
  • Pionowa struktura (squad) – to odpowiedź na pytanie CO? Product Owner to „przedsiębiorca” skupiony na dostarczeniu świetnego produktu
  • Pozioma struktura (chapter) – odpowiada na pytanie JAK? Służy przede wszystkim kształceniu kompetencji i wymianie wiedzy. Chapter leader to „profesor” dbający o doskonałość rzemiosła swoich ludzi.

O architekturę, oraz kontrolę długu technicznego, wg modelu Spotify dbają:

System Owner – doświadczona osoba ze squadu, do której inni udają się z potencjalnymi problemami. Koncentruje się na takich kwestiach jak jakość, stabilność, skalowalność, proces wydania. Właściciel nie musi osobiście robić wszystkiego, jednak od czasu do czasu bierze „dzień właściciela systemu” i wykonuje prace porządkowe w tym systemie.

Chief Architect – osoba, która koordynuje prace nad zagadnieniami architektonicznymi na wysokim poziomie w wielu systemach. Przegląda rozwój nowych systemów, aby upewnić się, że są zgodne z wizją architektoniczną i nie powielają błędów. Proponuje ulepszenia – decyzja o ostatecznym projekcie systemu nadal należy do zespołu, który go buduje.

 

LeSS

Head of the Product Group – Większość organizacji LeSS nadal ma menedżerów, w tym „szefa grupy produktów”. Wspierają zespoły, pomagają im usuwać przeszkody i ulepszać się – budować zdolność wytwórczą. Organizacje LeSS nie mają struktur matrycowych, przede wszystkim skupiają się na elementach organizacji produktowej.

„Szef grupy produktów” nazywa się inaczej w różnych organizacjach, tutaj mamy na myśli menedżera hierarchicznego wszystkich zespołów.

Feature teams – właśnie tam wykonywane są prace programistyczne, jest międzyfunkcjonalnym (ang. cross-functional), samoorganizującym się zespołem ze Scrum Masterem. Są to stałe jednostki, które pozostają razem przez cały czas trwania produktu (a czasem dłużej). Unikamy zbyt dużej liczby warstw hierarchicznych.

Product Owner (Team) – jest to również powszechnie nazywane „Zarządzanie produktem”. Może to być jedna osoba, w większej organizacji Product Owner może być wspierany przez innych menedżerów produktu. Ważnym punktem w tej strukturze organizacyjnej jest to, że Zespoły i Właściciel Produktu (Product Owner) są rówieśnikami (w hierarchii). Jest to istotne, aby zachować równowagę między rolami. Zespoły i właściciel produktu powinny współpracować ze sobą.

Alternatywną strukturą jest sytuacja, gdy Właściciel Produktu należy do innej organizacji. Jest to OK, choć często wymaga dodatkowego wysiłku, aby upewnić się, że Właściciel Produktu ma bliskie relacje z Zespołami.

Undone department – idealnie, gdy ten dział nie istnieje. Ale niestety czasami zespoły nie są w stanie stworzyć prawdziwego przyrostu możliwego do promocji w każdym sprincie. Odzwierciedla to fakt, że ich „Definicja ukończenia” nie jest równa „Potencjalnie dostarczalnej” (“Definition of Done” != “Potentially Shippable.”). Oddzielne grupy testujące QA, architektura lub analizy biznesowe, nie powinny nigdy istnieć w mniejszych podgrupach LeSS, lecz być zintegrowane z zespołami od początku. Z drugiej strony, niestety we wdrożeniach LeSS wciąż widzimy działy operacyjne lub produkcyjne, które często przekraczają granice organizacyjne.

Czego tutaj nie ma:

  • Brak PMO lub Departamentu Zarządzania Projektami/Programami – tradycyjne organizacje kontrolne przestają istnieć w organizacji LeSS, ponieważ ich obowiązki są rozdzielone między zespoły (Feature Teams) i właściciela produktu (Product Ownera). Współistnienie takich organizacji powoduje często zamieszanie i konflikty odpowiedzialności.
  • Brak grup wsparcia, takich jak zarządzanie konfiguracją, wsparcie ciągłej integracji lub „jakość i proces”. Organizacje LeSS wolą rozszerzyć obowiązki istniejących zespołów, aby uwzględnić tę pracę nad tworzeniem bardziej złożonej organizacji z wyspecjalizowanymi grupami.

Wyspecjalizowane grupy wsparcia mają tendencję do „posiadania” swojego obszaru, co powoduje, że stają się wąskim gardłem.

Współzależności poszczególnych ról w LeSS ładnie obrazuje oficjalna grafika ze strony:

***

Była jeszcze taka bajka o Czerwonym Kapturku, który szedł przez las i spotkał SAFe Practitionera, ale to może już kolejnym razem… 😉

Mam nadzieję, że ten wpis pomógł Wam złapać kontekst, oraz uporządkować nieco wyobrażenie o tribe’ach, czy ogólnie zwinnych strukturach organizacyjnych w skali.

Zachęcam do kontaktu jeśli zastanawialibyście się, jaki model najbardziej pasowałby do Waszej sytuacji.

Źródła:

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

https://less.works/less/structure/organizational-structure.html