.st0{fill:#FFFFFF;}

Prawdziwy Model Spotify 

 16 października, 2019

Tomasz Dzierżek

Model Spotify to nasze agile’owe nemezis. I wcale nie chodzi o to, że jest w nim coś z gruntu złego. Ale ta dobra w swoich założeniach idea wyrządziła wiele szkody naszemu zwinnemu środowisku.

 

Skąd się wziął Model Spotify?

W październiku 2012-ego roku, a więc siedem lat temu, Henrik Kniberg i Anders Ivarsson opublikowali słynny już dokument o nazwie „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”, od którego wszystko się zaczęło.

Podstawową komórką organizacyjną w Spotify był Squad, który zorganizowany został podobnie dobrze nam znanego Scrum Teamu. Squady w założeniach miały działać jak mini-startupy i skupione były na małych fragmentach funkcjonalności (np. „Polecane albumy i utwory w aplikacji webowej”). Były one też samoorganizujące się – niektóre z nich używały Scruma, inne Kanbana, a jeszcze inne – rozwiązań autorskich.

Każdy Squad miał swojego Product Ownera, który zarządzał backlogiem oraz Agile Coacha, który wspierał zespół. Ten ostatni nie mógł się nazywać Scrum Masterem, ponieważ nie każdy zespół pracował w Scrumie. Zasadniczo jednak Agile Coach był odpowiednikiem SM-a.

Kilka Squadów zajmujących się jednym obszarem, np. odtwarzaczem muzyki („plejerem”), zorganizowane było w Tribe’y. Na czele tych ostatnich stali Tribe Leaderzy, którzy dbali o odpowiednie środowisko i mniej lub bardziej nadawali kierunek rozwoju produktu i zajmującego się nim „plemienia”. Można zaryzykować stwierdzenie, że Tribe Leader to Product Owner, a spotify’owy PO to swego rodzaju Proxy Product Owner. Oczywiście, jeśli te backlogi są zupełnie niezależne to wtedy spotify’owy PO to po prostu PO, a Tribe Leader – kierownik, manager, Master/Area Product Owner.

Do tego dołożone zostały jeszcze tajemniczo brzmiące Chaptery. Te z kolei, to nic innego, jak grupy osób o podobnych kompetencjach w ramach jednego Tribe’u, np. developerzy aplikacji na Androida, testerzy automatyczni. Gdyby tego było mało, to czasami pojawiały się też kross-zespołowe inicjatywy obejmujące różnych ludzi z wielu Tribe’ów. Takie konstrukcje nazwane zostały Gildiami i nietrudno nam sobie wyobrazić Gildię Scrum Masterów (Agile Coachów), czy np. zadaniową Gildię RODO.

W tym opisie oczywiście pominąłem wiele niuansów. Np. na czele Chapterów stali kierownicy liniowi (np. przełożony wszystkich analityków w danym Tribie, team leader developerów, itp.). Społeczności gildiowe z kolei miały swoich koordynatorów.

Zainteresowanych szczegółami odsyłamy do źródła.

 

Model Spotify nie istnieje

Powiedzmy to wprost: nie ma czegoś takiego, jak „Model Spotify”. Wbrew temu, co głoszą niektórzy agile coache i prezesi, nie da się „wdrożyć Modelu Spotify”. A przynajmniej nie wygląda to tak, jak sobie to wyobraża większość osób głośno wypowiadających się na ten temat.

Zresztą, taką nadinterpretację przewidzieli panowie Kniberg i Iversson. Odpowiednie ostrzeżenie umieścili od razu na pierwszej stronie.

„Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working – a journey in progress, not a journey completed. By the time you read this, things have already changed.” – Scaling Agile @ Spotify

Cały „Model Spotify”, na którym niezliczone firmy wzorują swoje transformacje agile, to nic innego jak obraz organizacji jednej konkretnej firmy na pewien określony dzień w roku 2012. A to znaczy, że sytuacja wyglądała tam zupełnie inaczej zarówno kilka lat wcześniej, jak i kilka lat później.

Pamiętajmy też, że liczność zespołów deweloperskich ewoluowała razem z „modelem”. Spotify urosło z około trzydziestu ról deweloperskich w 2009 roku do dwustu pięćdziesięciu w 2012. A to znaczy, że „Model Spotify” z 2012 roku nie zadziałałby w tej samej organizacji w żadnym innym momencie. Jestem też absolutnie przekonany, że gdyby Spotify chciał dziś wdrożyć „Model Spotify”, to skończyłoby się to porażką.

Model Spotify opisany w dokumencie „Scaling Agile @ Spotify” jest tylko obrazem rozwiązania, które zostało zoptymalizowane dla jednej konkretnej firmy, w jednym momencie czasu i przy bardzo specyficznych okolicznościach przyrody. Polecam poczytać o dość ścisłym podziale kompetencji pomiędzy poszczególnymi Tribe’ami i Squadami w Spotify. Jeżeli nie pracujemy w ten sam sposób nad naszym produktem, to trudno się spodziewać, że u nas takie podejście sprawdzi się równie dobrze.

Bo tak naprawdę ten cały „Model Spotify” nie był stworzony. On stworzył się sam.

 

Ewolucja, a nie rewolucja

Pamiętajmy o tym, jak powstał cytowany w niniejszym tekście dokument. Był to opis ówczesnego stanu organizacji o nazwie Spotify, poczyniony na podstawie obserwacji. To bardzo ważne. Niektórym wydaje się, że panowie Kniberg i Ivarsson sami wymyślili taki, a nie inny model, który dopiero potem wdrożyli go w tej firmie. Tymczasem było dokładnie odwrotnie. To Spotify dał wolną rękę zespołom, które zorganizowały się tak, a nie inaczej.

„This scaling model – with Squads, Tribes, Chapters, and Guilds – is something that was introduced gradually over the past year, so people are still getting used to it.” – Scaling Agile @ Spotify

Zwróćmy uwagę na fragment „gradually over the past year”, który stoi w poprzek marzeniom prezesów i dyrektorów, którzy chcą „Przeszkolić 1500 osób z modelu Spotify.” Po pierwsze, samo dojście do takiego etapu, jaki został opisany w dokumencie, zajęło lata. Tego się nie da zrobić szybką, kilkumiesięczną transformacją. Po drugie, nic tu nie zostało narzucone z góry.

Prawdziwy „Model Spotify” to powiedzenie zespołom, że mogą pracować jak chcą, a następnie zamknięcie oczu i zaciśnięcie kciuków, licząc na to, że uda się stworzyć coś efektywnego. Dlatego tak ważne jest, aby mieć na pokładzie Scrum Masterów i/lub Agile Coachów, którzy tym całym procesem pokierują, a przynajmniej będą nad nim czuwać.

Bo nawet zwinność musi mieć jakieś ramy. Zespoły nie będą decydowały o strategii biznesowej, ta spłynie do nich za pośrednictwem PO. Tak samo nie będą one wymyślać sobie podziału na obszary i zespoły, czy też kombinować z przydziałem samych Product Ownerów do poszczególnych produktów. Część tych ograniczeń i ustaleń musi pochodzić z organizacji. Ktoś musi też nadawać jeden kierunek, posiadać jakąś wizję produktu i do niej dążyć.

 

Zróbmy własny „Model Spotify”

Jeżeli marzymy o wprowadzeniu „Modelu Spotify” w naszej organizacji, zróbmy to samo, co zrobił Spotify. Po pierwsze – dobrze poznajmy sposób, w jaki działamy. Potem podzielmy się na małe, zadaniowe, „start-upowe” zespoły. Na koniec zaś, zaufajmy naszym zespołom, dajmy im wolną rękę w kwestii samoorganizacji i pozwólmy im wykształcić potrzebne im mechanizmy. Zapewnijmy środowisko, pozwólmy (a nawet zachęcajmy) do spotykania się w grupach roboczych i zadaniowych.

Bo nie jest przecież tak, że jak tylko damy wolną rękę naszym pracownikom, oni zaczną marnować czas na spotkania. Przecież zwykle sytuacja wygląda zupełnie odwrotnie. Raczej słyszymy komentarze w rodzaju „Zostawcie programistów w spokoju!

Skoro więc np. nasi testerzy automatyczni sami z siebie zdecydowali się spotykać raz w tygodniu i omawiać bieżące problemy oraz wymieniać się doświadczeniami, to raczej odpowiada to na jakieś ich potrzeby.

Jeżeli takie spotkanie nazwiemy „Chapterem testerów automatycznych w obszarze X”, to już możemy się chwalić, że mamy zalążki „Modelu Spotify”. Bo w podobny sposób wykształciły się wszystkie elementy opisany w tym nieszczęsnym dokumencie. To nie było tak, że ktoś krzyknął „Zróbmy tribe’y, chaptery i gildie!”, tylko one powstały, bo Spotify mierzył się z pewnymi określonymi problemami.

Weźmy pod lupę same Tribe’y. To nic innego, jak obszar z jednym wspólnym backlogiem, który realizowany jest przez kilka zespołów i przy wsparciu Proxy Produt Ownerów. Identyczne rozwiązanie znajdziemy w modelu LeSS, gdzie Tribe Leader nazywany jest Area Product Owner. Inne spojrzenie na Tribe’y to w miarę niezależni PO ze swoimi prywatnymi backlogami zebrani w jeden… obszar. To tylko pokazuje, że w wielu różnych zakątkach świata organizacje trafiają na podobne problemy i rozwiązują je w bardzo zbliżony sposób.

Zamiast więc małpować nieistniejący „Model Spotify”, zróbmy nasz własny. Pozwólmy ludziom samodzielnie rozwiązywać swoje problemy organizacyjne i zapewnijmy środowisko, które pozwoli im to robić z łatwością. Na pewno otrzymamy rozwiązanie o wiele bardziej dopasowane do naszych potrzeb, niż przestarzała, siedmioletnia kalka jakiejś szwedzkiej firmy.

 

Jeżeli jesteście zainteresowani, jak pracować zwinnie w dużych organizacjach, zapraszamy na nasze szkolenie pod tytułem Skalowanie Scrum, gdzie omawiamy różne podejścia do zwinnej pracy w kilka, kilkanaście i kilkadziesiąt zespołów.

Tomasz Dzierżek


18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}